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. 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.
I'm not sure I figure the logic. Java statically disallows a number of
programs that in C++ are allowed and would be correct. It also disallows
statically a number of programs that in C++ are allowed, and that are
not correct. Now, for a _subset_ of the latter (incorrect) programs,
there are tools to help. This is my understanding of the situation. From
these facts, I fail to draw more interesting conclusions than (1) there
are programs accessible to C++ that aren't accessible to Java, and (2)
C++ is more dangerous than Java.
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.
It can't help you in the same way a kevlar glove won't help you shoot a
gun that won't explode in your hand. Maybe the safe gun is less
powerful, but I don't know how you can use the glove as an argument to
prove anything. I totally fail to understand the logic. I know analogies
suck, but I have to confess I'm so lost, they might help.
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 think I can answer that one.
Fewer programs are allowed. So if the language designer took the right
turns, many "wrong" programs would be statically eliminated, and few
"good" programs. So by simple set theory, we could infer under these
assumptions that fewer programming errors will make it.
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. 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.
I think of it this way: let's start from an entirely safe language (no
UB). It allows a set of correct programs and another set of incorrect
programs to be written.
Now, say I start to add features exhibiting UB. Then with each feature I
create the opportunity for more programs to be written. Some of those
programs will be correct (and not expressible in the safe language), and
some of them will be incorrect (and also not expressible in the safe
language).
By adding a feature with possible UB, you may increase the set of
incorrect programs more than increasing the set of correct programs. So
at least in principle you increase the likelihood of wrong programs
being written.
Of course this glosses over a number of details, such as counting the
number of programs (which in a naive approach will be infinite, so a
number of equivalence classes must be defined) and including the
posterior probability of each program being written, yet I think it does
illustrate a point.
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]