Re: The D Programming Language
"Andrei Alexandrescu (See Website For Email)"
<SeeWebsiteForEmail@erdani.org> writes:
David Abrahams wrote:
"Andrei Alexandrescu (See Website For Email)"
That said, even in a system with no undefined behavior, we have no
idea what the value of x (or anything else in our program) is after a
programming error, so the ability to continue on with the program
executing the instructions you thought you were giving it originally
is not as valuable as it might at first seem.
It's not "anything else in our program". It's "anything else in our
program that was affected by x"
No, not at all. Re-read the scenario; "x" didn't necessarily have
anything to do with the programming error. From a practical point of
view, by the time your internal checks/assertions have detected that
there's been a programming error by inspecting some piece of program
state (call it Z), you have no idea how far the damage has spread.
That is, the program's own guarantees are out the window.
I disagree. As I explained before: in Java bugs can be made modular in
ways that are not possible in C++, because you have true memory
isolation between objects.
True memory isolation is very nice, but I don't see how it helps make
bugs modular in practice. Once you discover something is wrong you
have no way of knowing where the code causing the wrongness was or
what the wrongness has affected [see below].
When I make that claim about C++ I am never thinking specifically
about references through invalid pointers, because that basically
never happens to me anymore. I'm just thinking about what happens to
the program state.
One way to think of this is that if you imagine the use of
FORTRAN-style data structures with indexing instead of pointers (and
actually I think in some sense you need these in Java because there's
no pointer arithmetic), even integers can "dangle." Just shorten an
array and there you are. So I don't think there's anything intrinsic
in keeping pointers valid (even if valid only means pointing to an
object that should really be gone) that limits the spread of broken
invariants.
[below] Okay, I suppose it's possible to write subsystems that make
absolutely no assumptions about what their clients pass other than
what's guaranteed by the type system, and if those subsystems have no
bugs, you know these subsystems still intact -- a valuable property
for diagnostic subsystems like loggers.
However, I doubt the practicality of writing whole systems that way.
Eventually you'll end up with functions that require a certain
relationship between parameters (e.g. end >= begin), and then to
maintain the "no assumptions about the inputs" stance you have to
check these relationships, and throwing an exception becomes part of
the function's defined behavior. Since the function calling with
arguments (end < begin) is already holding broken data or broken
assumptions, all hell then breaks loose.
Meaning that in Java, all writes of "references" (a.k.a. pointers) are
synchronized?
That is correct. They are guaranteed to be atomic; there is no invalid
reference in Java, ever, period.
Wow; that does sound slow :)
and because there's no pointer forging, that reduces to "any other
number that was affected by x", which considerably reduces the rot
in the program and the difficulty in spotting it. I guess all I can
say is that I tend to see that guarantee as much more valuable. :o)
Than what?
Than "all the hell breaks loose starting at this point".
Oh, but that's not guaranteed either. If you're going to compare
value, you should compare the Java guarantee against:
* better speed
* the flexibility to respond to errors in special ways
* (I had another but then it flitted away)
Anyway, I'm not claiming to know what's more valuable in the long run,
I'm just challenging what I think are some of the usual assumptions
around this question, one of goes something like, "undefined behavior
in a language has no merits."
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]