Re: Undefined behaviour [was Re: The D Programming Language]
David Abrahams wrote:
"James Kanze" <james.kanze@gmail.com> writes:
Ian McCulloch wrote:
David Abrahams wrote:
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.
Completely backwards.
Not really.
You can only _use_ such tools because of the
undefined behavior. You still need something to detect the incorrect
logic that in C++ would have caused UB and in Java causes
who-knows-what "defined" behavior. But no such tool exists, or can
exist.
There are obviously cases of incorrect logic which no tool will
detect. Be it Java or C++. There are also types of errors
which are impossible in Java---you can't delete a local
variable, for example, since Java doesn't have local variables.
(That can lead to other problems, of course, since it isn't rare
for two objects to "share" a variable without realizing it.)
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,
That's more on target. It can't help you.
But that's because the types of problems you encounter are
problems where it couldn't help you in C++, either.
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.)
Right. The question is, does the elimination of UB (which, remember,
is a *response* to programming errors, not a cause) actually in and of
itself make it harder to make programming errors? I don't see how it
could.
I'm afraid that I prefer determinism over indeterminism. In
case of an error, I'd prefer an immediate crash, but I prefer a
guaranteed exception over might crash, might do something else.
And there are some types of errors which are only errors because
the C++ standard decided that the behavior would be undefined or
unspecified. Things like order of evaluation.
Now, we can ask whether the design of Java in general makes it
harder to make programming errors. It may do that, I don't
know. But it's not because the language spec says there's no
UB.
The language specification doesn't say that there's no UB.
There are some very definition cases of UB (it's possible to
attempt to access an object through an uninitialized reference,
for example), and there are others where the behavior isn't
fully specified. On the other hand, it does eliminate some
cases of gratuous undefined behavior, which does help avoid some
errors, and by making other cases more strictly reproduceable,
it helps too.
AFAICT, the only
thing that the presence of UB can possibly affect is debuggability,
and as I've posted elsewhere, I doubt the effect is entirely negative.
The effect is only positive when the implementations actually do
define the behavior, which is rarely the case.
--
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! ]