Re: The D Programming Language
James Kanze wrote:
Andrei Alexandrescu (See Website For Email) wrote:
I guess the set of "all hell breaks loose" is much larger, and includes,
the set "there is one incorrect value". I am sitting here in amazement I
have so much trouble getting this point across.
Certainly. The only point I'm trying to make (here---there seem
to be multiple issues being discussed in parallel) is that even
with Java's "defined behavior", all hell can break loose. That
both are really "undefined behavior".
Except that we're not really discussing the undefined behavior I
find in Java. I agree that requiring error checking is a good
thing. And that C++ has too much undefined behavior, especially
in a lot of cases where there's absolutely no need for it.
Somehow, the argument has gotten away from my statement that all
languages have some forms of undefined behavior.
And I disagree with that statement - as simple as that. There are
definitely languages (Haskell, ML) that do not have undefined behavior.
So you'd need at least to qualify your statement with "all non-academic
languages have some forms of undefined behavior".
Even after that qualification, I still disagree with you, subject on how
you define "undefined behavior". If you define "undefined behavior" as
in C++, then I flat out disagree with you. If you defined "undefined
behavior = produces undefined numbers", then I'd agree. The fact that
we're in a C++ forum suggests that "undefined behavior" carries the C++
conotation of the phrase, which is "there is no guarantee about this
program henceforth". So I want to clear that out.
To summarize so far: (1) I find your statement "all languages have some
forms of undefined behavior" wrong because there are languages, be they
academic or of limited market penetration, that do not have undefined
behavior; (2) Even after we restrict the statement to industrial
languages, the statement is still wrong because it uses "undefined
behavior" with its implicit C++ meaning.
On the other hand, it's impossible to eliminate it entirely;
some of it comes directly from the hardware we run on, and
eliminating other cases (e.g. some of the threading issues)
really does impose unacceptably high run-time costs.
IMHO the whole non-deterministic hardware branch of discussion is a big
smelly red herring pulled on the trail. This is not a hardware forum. We
discuss the whole issue within the confines of a hardware model, and
artificially taking the discussion to metaphysical levels would only
lead to purpose-of-life kind of questions.
Try doing any multithreaded programming without proper
synchronization, and you'll get unpredictable results. The
language standard doesn't specify what happens globally, even if
it tries to specify most individual accesses. And if what
happens isn't defined, how can you say that it isn't
"undefined".
I Java, I'll get wrong numbers but never violated objects. The program
remains well-defined, only the numbers subject to races have undefined
content.
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]