Re: The D Programming Language
Andrei Alexandrescu (See Website For Email) wrote:
James Kanze wrote:
Andrei Alexandrescu (See Website For Email) wrote:
David Abrahams wrote:
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.
For a particular definition of "invalid". As Jean-Marc pointed
out, you can very easily end up with pointers to invalid
objects.
I said "invalid pointer", not "pointer to invalid object".
"Invalid pointer" = typed pointer pointing to a region of memory that
the program does not assume is of that type.
I'm having trouble parsing that last statement.
Be it Java or C++, you can end up with a pointer to a destructed
object. Raw memory, in sum. In C++, that's called an invalid
pointer. In C++, of course, there are also other ways of
getting invalid pointers---just forget to initialize one, for
example, and the problem is made worse by the fact that the
system may reuse that raw memory for some other object, perhaps
of a completely different type. But in the end, saying that a
pointer is valid when it points to an object that has ceased to
live, and is no longer usable is just playing word games.
I think you and I basically agree here (based at least partially
on earlier discussions concerning garbage collection). There is
an enhanced degree of safety in Java in this regard. But I
don't like statements like "there is no invalid reference" or
"you cannot leak memory" (which one often hears)---they give a
false sense of security.
I can't help it. As far as I know there is no invalid reference, but
there are ways to leak memory.
Whether they exist or not, I've seen both in real Java programs.
I agree there could be references to objects in states that you didn't
expect.
If you consider "no longer logically existing" as a state you
didn't expect. In practice, the problem is pretty much the same
as that of a dangling pointer in C++: in Java, you could
potentially protect against it, and detect the case (not that
anyone does), where as in C++, there's a good chance of the
program crashing, which you can't ignore (but it's not
guaranteed, and all too often, where it crashes is far from the
offending code).
It's much easier to protect against
accidentally using an invalid object, since the memory
containing the object cannot be used for any other use as long
as there is a pointer to it, but the object may still be
invalid.
Oui. The thing is, the program invalidated the object itself with
operations defined by the object; it wasn't invalidated as result of
some unrelated invalid object.
But that doesn't stop it from being undefined behavior. If I do
"delete p" in C++, then use p, p wasn't invalidated as a result
of some unrelated invalid object.
I agree that there are a lot more ways to get undefined behavior
in C++ than in Java. But some of the ways work in both
languages: violating thread safety, etc. And while I don't
think I'd consider using a pointer to a "disposed" object really
undefined behavior in Java, the effect can often be pretty much
the same. (It's not undefined behavior, IMHO, because you can
establish invariants which can be checked at runtime. It's
pretty much the same thing because people don't, including the
people who wrote the standard libraries.)
--
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! ]