Re: Undefined behaviour [was Re: The D Programming Language]
Ian McCulloch wrote:
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. 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.
Right - and there are systems that already do this. Valgrind (
http://www.valgrind.org/) springs to mind at this point. In the face of a
programming error, you want as much `undefined' behaviour as possible, to
give the tools that detect such behaviour the most information possible.
Except that you only need such tools because of the undefined
behavior. Limit the cases of undefined behavior to the few that
show up in Java, and you don't need valgrind. Or rather, it
doesn't help you, because it doesn't detect race conditions,
etc., either. (At least, I don't think it does.)
I think valgrind is the single most useful debugging tool on Linux, even
though I don't use it that often, much less frequently than a debugger, or
even printf() debugging[*]. AFAIU valgrind would be completely useless for
debugging java programs,
Because most of the types of errors it finds aren't possible in
Java. (The last error I found with valgrind was someone
deleting a local variable, for example. Impossible in Java.)
which leaves a few possibilities: (1) the Java (or
D?) language design is such that bugs that are typically caught by valgrind
would never be made in the first place, or (2) Java debuggers already cover
this functionality, or (3) Java programs are harder to debug than C++
programs. I wonder which?
With regards to what valgrind does, it is the first. Of course,
there are a lot of other issues, and I find that (3) is also
true (or perhaps rather that it is more difficult to write
programs that you know are correct---in C++, debugging is
typically less than 10% of the development time, where as in
Java, you end up with a lot more bugs to begin with).
Undefined behavior is bad,
I don't think that's been demonstrated, and I challenge it as an
axiom.
Whether undefined behavior is badly expressed in today's running C++
programs is another matter.
I agree. But each instance of undefined behaviour needs to be treated on
its merits. There are surely at least a few places in C++ where undefined
behaviour isn't very helpful, or easy to diagnose.
And how. And as you say, there are cases where it is necessary.
You cannot write a device driver within the "defined behavior"
of either C++ or Java.
[*] This looks really anachronistic. But have you ever seen anyone
write 'std::cerr<< debugging' ??
It's pretty much the standard for a quick fix.
In practice, for me it is spelled
TRACE(X)(Y)(Z) anyway.
In production code. Except that it is something like:
LOG( trace ) << X << Y << Z ;
For quick proof of concept programs, however, the "LOG( trace )"
is just std::cerr. Even though that results in undefined
behavior. (My applications are multithreaded.)
--
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! ]