Re: The D Programming Language
Andrei Alexandrescu (See Website For Email) wrote:
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?
I think it's one thing to have a wrong numeric value and one very
different thing to have a program in which all hell breaks looks due to
random overwriting of memory.
But nobody's really disagreeing. Being able to accidentally
randomly overwrite memory is hardly what I would call a feature.
(Being able to do it intentionally, e.g. with a
reinterpret_cast, is a necessary feature if you want to develope
kernel code, but that's a different issue.)
On the other hand, faced with a serious program error (e.g.
inconsistent values resulting from a race condition), having all
hell break loose is certainly preferrable to silently continuing
and pretending that all is well. And issuing a market order to
buy when our customer said sell.
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++.
Well the only thing I can add is that in my limited experience,
debugging Java programs is much easier because there's never the case
that a dangling pointer misteriously overwrites some object it wasn't
supposed to.
That's not been my experience. I found debugging Java programs
exceedingly difficult---the event handler in AWT/Swing silently
ate all exceptions, so when you dereferenced a null pointer, you
simply silently didn't finish handling the event, rather than
crashing noisily.
More importantly, of course, I found writing correct programs in
Java considerably more difficult, because everything derived
from object, and your collections weren't typesafe. Which meant
I had a lot more debugging to do---in general, in C++, if my
code passes the compiler, it works. (Not always, of course, but
in general, after successful compilation and code review, I can
count on one error per 100000 lines of code in C++, but close to
10 times as many in Java.)
I'm not sure how such personal anecdotes relate to the undefined
behavior issue, however. I don't think that there's any doubt
that Java has a lot less undefined behavior than C++: you claim
zero, and I claim that there are a very few special cases, where
as C++ has it all over the place. I don't think that there's
any doubt either that undefined behavior is bad, in itself. And
I certainly hope we agree that it is only one factor, and that
there are a lot of other factors which affect the difficulty of
writing correct code, or debugging incorrect code. (The biggest
problems I had in debugging Java were due to the defined
behavior doing the wrong thing---throwing an exception rather
than crashing---and an incredibly stupid decision to ignore the
exception in the standard library. That and the lack of strong
typing on variable sized containers---I understand that has
since been fixed.)
I remember __to this day__ a night in 1998 when a colleague
and myself spent one night figuring out a completely weird exception
being thrown (in a C++ program) under very complex circumstances - just
because of a misfit memcpy() in a completely different and unrelated
part of the program. Now that I think of that, I remember a few others.
Probably I'd remember even more under hypnosis :o). To tell the truth, I
also remember of a JVM bug causing me a few gray hairs... :o)
But that's defined behavior in Java. According to the standard,
if the JVM has a bug, it's supposed to throw the
VirtualMachineError exception, no? :-)
(FWIW: the bug that took me the most time to find was when the
hardware changed a bit in the program. Always the same bit, and
only once or twice per day. Memory wasn't protected back then,
and it took us well over a month to determine that it was
hardware, since all of the hardware tests said that everything
was fine.)
--
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! ]