Re: The D Programming Language
David Abrahams wrote:
"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.
Sure it helps. A lot, even, if you want it to. But it isn't a
panacea, or a silver bullet. It's just one more tool. It can
reduce the number of places where you have to look, even if it
won't tell you exactly what's wrong.
Why all the extremist positions? You're saying it won't help;
Andrei says it eliminates all forms of undefined behavior.
Personally, I think it helps a lot, but there are problems it
doesn't solve, and there are other forms of undefined behavior
which have to be dealt with, at least in real programs running
on real machines.
In the end, I find it easier to write robust code in C++ than in
Java, but it's despite the way pointers work in C++, not because
of it.
[...]
[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.
The problem isn't the practicality of your writing a whole
system this way. The problem is that you will be using
libraries that you don't write that weren't written this way.
And also...
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.
One of Java's faults is that it doesn't allow you to do anything
reasonable (like crashing) when you've detected the problem.
All you can do is log the error and throw an exception, hoping
that 1) nobody silently swallows the exception (except that
major standard library components do silently swallow
exceptions), and 2) someone reads the log, and notices what went
wrong.
(Actually, part of this is related to mentality. At least under
Unix, you can set SIGSEGV to SIG_IGN, and carry on. But nobody
does this, whereas, As I said, major standard library components
in Java silently gobble up exceptions.)
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 :)
I get the feeling that Andrei is confusing atomic and
synchronized. Writes to pointers in Java are guaranteed to be
atomic; they're not "synchronized", neither in the usual sense,
nor in the Java language sense.
Of course, this means that other threads can see pointers to
objects which aren't yet constructed. But that's generally true
in Java, even without threads; just call a virtual function from
a base class constructor. Worse, other threads can see pointers
to objects which haven't yet been zero initialized (or
initialized at all). That is, of course, the undefined behavior
that Java supposedly doesn't have. (I'm rather surprised that
Andrei doesn't recognize this. IIRC, he's written on the
problems of double checked locking in the past, and this problem
is related.)
--
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! ]