Re: The D Programming Language
David Abrahams wrote:
"Andrei Alexandrescu (See Website For Email)"
<SeeWebsiteForEmail@erdani.org> writes:
There might be a terminology confusion here, which I'd like to clear
from the beginning:
1. A program "has undefined behavior" = effectively anything could
happen as the result of executing that program. The metaphor with the
demons flying out of one's nose comes to mind. Anything.
2. A program "produces an undefined value" = the program could produce
an unexpected value, while all other values, and that program's
integrity, are not violated.
The two are fundamentally different because in the second case you can
still count on objects being objects etc.; the memory safety of the
program has not been violated. Therefore the program is much easier to
debug.
Seriously?
IME you're at least likely to crash noisily close to the undefined
behavior. If you make everything defined the program necessarily
soldiers on until one of your own internal checks is able to notice
that something went wrong. Or am I missing something?
The idea that "undefined behavior" equates to a program crash is a
popular misconception among C+ programmers, and is one the reasons
undefined behavior is often minimized as a problem in C++ programming.
This argument is really saying that C++'s undefined behavior is not
undefined at all - but instead results in the flawed program's
termination. So by a serendiptious stroke of luck, it turns out that
undefined behavior is the same as the ideal behavior - so how can
undefined behavior be a problem?
And much of the time, the C++ programmer is right: the undefined
behavior does terminate the program - but no credit should go to C++.
Rather it is the OS and the runtime that have filled in where the
Standard has been remiss, by defining otherwise undefined behavior. An
obvious example is the dereferencing of a NULL pointer - the
consequences of which are undefined by the Standard, but defined on
almost every modern architectures as a fatal memory access error. So
the fact that this supposedly "undefined behavior" is in fact very
well-defined on most platforms - is what leads to the common
misconception among C++ programmers that all undefined behavior in the
language leads to the same. But of course that is a very mistaken
conclusion..
And in fact in none of these problematic examples cited in this
discussion, lend any support to the believe that a C++ program would be
any more likely to terminate than the Java program in the same
situation. Certainly non-atomic accesses are likely to be too expensive
to detect on a given hardware, and I'm not familiar with any such
error. Of course the reverse argument could also be made: that C++'s
undefined behavior be no different than that of the Java program, so
C++ is none the worse of for it. But if undefined behavior were so
well-behaved, then why can't the Standard just state that that is the
case?
I don't have any real experience with Java, but Python generally
exhibits Java-like behavior, and I don't find it easier to debug than
C++.
I have found Perl almost trivially easy to debug compared to a C++
program. With C++programming there are two levels of correctness to
worry about: first, the program must behave correctly (that is, have
defined behavior at all times) and, second, this correct behavior must
match the behavior that the programmer wants. A Perl (or Java)
programmer does not have to worry about the first level, the program is
always behaved - in other words, it always does what the programmer
tells it to do. So the only concern left is for the programmer to tell
the program what it should be doing in order so that it can produce the
expected (or "correct") results. So in essence a Perl programmer is
already halfway done writing a program compared against the starting
point of a C++ programmer, and this is before eiher programmer has
written a single line of code (OK, that's an exagerration, but it is a
valid point nonetheless).
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]