Re: The D Programming Language
"Greg Herlihy" <greghe@pacbell.net> writes:
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,
Yes, but not one that I share. I just said a crash was likely.
And much of the time, the C++ programmer is right: the undefined
behavior does terminate the program - but no credit should go to
C++.
Not quite true. When a program enters "undefined behavior territory"
the implementation (or a 3rd party tool) is free to take the ideal
action. Undefined behavior is about implementor freedom, too.
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.
Yes, but fortunately the response is observably outside the normal set
of results that the program can produce. Defined behavior is nicely
corralled off from everything else and (yes, in this case and not in
all cases) there's no chance of soldiering on without being able to
observe the problem.
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 understand what you're suggesting, but the answer is simple:
implementor freedom.
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.
To a first approximation, that's true in C++ until you tell the
program to do something illegal.
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).
I can certainly agree that you've dramatically overstated your case
here.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]