Re: The D Programming Language
David Abrahams wrote:
"James Kanze" <james.kanze@gmail.com> writes:
I'd even go further and say that I prefer the Java
solution of consistently doing the wrong thing to that of C++,
which results in inconsistent and untestable behavior.
I agree that the behavior is often inconsistent. I disagree that it's
untestable in practice. One of my points is that labelling some
behavior undefined can improve testability, because the system can
then things observably outside the realm of defined behavior.
If the system defines the behavior to do the right thing, that's
obviously even better than consistently doing the wrong thing.
I think Andrei's point is that 1) C++ doesn't require this of
the system, and 2) most systems don't really make too many
additional guarantees in this regard. In particular, there's no
guarantee that an invalid pointer will crash the program---my
experience has been that most invalid pointers are a result of
using already freed memory, and without Purify, it's pretty much
guaranteed (at least under Solaris and Linux) that using such a
pointer won't crash the system immediately.
It's
true that it's a crapshoot whether the behavior of most running C++
programs will be observably undefined, but that is technically
speaking an implementation artifact, for efficiency. There's no
reason in principle that a C++ system couldn't be written that
immediately detects way, _way_ more of the errors that lead to
undefined behavior and invokes a debugger immediately. Every pointer
dereference could be fully checked, for example.
More or less what Purify does, in other words. Or (I think)
CenterLine used to do.
Regretfully, very few implementations do this, and none that I
know combine it with intermodule optimization, which would allow
suppression of the checks when the compiler could prove that
they would succeed. (I seem to recall reading a study on bounds
checking in Pascal that found that the compiler could eliminate
80% of the checks, including almost all in tight loops. Which
means that full runtime checking is affordable, if the compilers
want to do it.)
Undefined behavior is bad,
I don't think that's been demonstrated, and I challenge it as an
axiom.
I don't see too much where it's challengeable. You certainly
aren't arguing for inconsistent and untestable behavior. If I
understand you correctly, you're arguing for implementations to
define the behavior which the standard leaves undefined. When I
say that undefined behavior is bad, I mean truly undefined
behavior, defined neither by the language nor by the
implementation.
Whether undefined behavior is badly expressed in today's running C++
programs is another matter.
I think that Andrei's point was that as soon as you start
restricting how it is expressed, it's no longer totally
undefined. I'm not sure that I completely agree with him, but
as a practical matter today, there's far too much undefined
behavior in C++, and the implementations aren't exploiting it to
produce more robust applications.
--
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! ]