Re: The D Programming Language
David Abrahams wrote:
"Andrei Alexandrescu (See Website For Email)"
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.
Well if we consider C++ code that never references the wrong memory, the
differences from Java narrow considerably, and whatever arguments I can
bring in the discussion narrows considerably.
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.
There is something intrinsic. The off-bounds integer can be easily
caught; the dangling pointer can't (unless it's implemented otherwise
than a memory address, which I don't see as interesting).
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.
I don't understand this part. Basically if you have memory safety it's
possible with language-provided encapsulation to define a type that is
able to preserve its own invariant. No? I don't see the hell breaking
loose. It's holding tight :o).
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 :)
It's not synchronized via a lock; it's just guaranteed to be an atomic
write. I think that's an important guarantee - it's one of the
guarantees that allows memory safety.
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."
Never claimed that. Features with undefined behavior confer efficiency
and expressiveness to programs. The art is finding ways to preserve as
much as possible the speed and the expressiveness, while statically
disallowing programs that aren't correct.
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]