Re: The D Programming Language
Andrei Alexandrescu (See Website For Email) wrote:
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".
But you don't explain how they define the behavior in some of
the cases I raise. My point is that taken in the most extreme
sense, it is impossible to exclude all undefined behavior. At
the very least, you have undefined behavior in cases of hardware
failure or human error in the implemention of the language. Of
course, you could say that in such cases, the implementation
isn't conform, but what does that buy us? All it does is render
a conforming implementation impossible.
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.
The C++ definition is that the language standard doesn't place
any restrictions on the implementation. I'm not sure how that
maps to languages which don't have a standard, but I don't feel
that that's the point. The point is what happens in practice.
And what happens in practice is that you do not know what
results the program are going to give. You can't predict them,
and you can't necessarily repeat them.
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.
The definition in the C++ standard is designed to apply to all
implementations, in all contexts. So I'm not sure that you can
even attempt to apply it to a language that isn't designed and
cannot be used for implementing system software. When you're
writing application code, the scope of "undefined behavior" is
limited. Posix limits it some, and the JVM limits it more. But
the final effect is that there are cases where you can have no
knowledge of what might happen (within the bounds the execution
environment places), you cannot predict it, you cannot count on
it, and you cannot even reproduce a given behavior.
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.
I won't argue too much about (1), because of course, I don't
know every language ever invented. All I can say is that
undefined behavior is widespread in language definitions, and I
pretty much feel that some forms of undefined behavior are
impossible to avoid. With regards to (2), I'm not sure what the
"implicit C++ meaning" is meant to be here. In practice, I know
that no matter what I do in my C++ application, I won't cause
demons to fly out of my nose, and I won't even reformat the hard
disk.
But I think we're arguing about vocabulary more than anything
else. And maybe I'm too influenced by having seen such things
as "no undefined behavior" being sold as a silver bullet. I
rather think you'd agree that a Java program can exhibit
undefined behavior (using the "usual" definition here, that you
cannot specify what it will do). In the end, whether this is
due to the language or something else is not all that important.
The fact that Java does specify some things which C++ doesn't
makes it easier for the programmer to avoid undefined behavior
in his program. (Other aspects of Java make it harder, of
course; RAII and making virtual functions private can be
powerful tools.)
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.
Hmmm. It seems rather the opposite to me. Talking strictly
about what the language guarantees, without taking reality into
account, is pretty much a metaphysical discussion, with no real
applications to the real world.
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.
What's the difference between "wrong numbers" and "violated
objects"? If an object no longer conforms to its invariants,
I'd say that it was "violated". Or is your point only that it
must be code which explicitly manipulates the object which
caused the problem? I would agree that, barring hardware
problems and errors in the JVM, in Java, you can't get
"undefined behavior" in an object you don't explicitly access
somehow. And that that's a very positive quality. (In French,
the word "violer" generally refers to rape. If you are trying
to say that C++ allows objects to be raped, and Java doesn't,
then I would agree, but I'd insist on pointing out that being
raped isn't the only way to get screwed.)
If that's your point, then I think we can agree.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]