Re: The D Programming Language
PeteK wrote:
Andrei Alexandrescu (See Website For Email) wrote:
However, we seem to be in danger of rehashing the argument we had about
GC vs smart pointers.
You can easily get rid of dangling pointers in C++ and turn them into
zombies instead by simply using a bolt-on garbage collector. The
language doesn't stop you doing that.
I'm not sure I understand your point. For the purposes of this
discussion, there are two fundamental types of data, those with
a determinate lifetime, and those with an indeterminate lifetime
(from the design point of view). For dynamically allocated
objects with an indeterminate lifetime, current C++ requires you
to explicitly use a delete expression, and make the lifetime
determinate (and risk dangling pointers). Java just does the
right thing. For dynamically allocated objects with a
determinate lifetime, C++ has a standard "name" for the function
terminating the objects lifetime, the destructor. It's a little
wierd, in that it doesn't have the normal function call syntax,
but big deal. Java lacks anything standard, but the convention
seems to be established to use the name "dispose()" (although
some of the standard classes use this name for other things).
In the end, it comes out to the same thing. Or almost---if you
want to, you can set state in the dispose() function in Java to
ensure that later use is detected. Immediately. To get this in
C++, you need something like Purify, and the runtime overhead is
high enough that you can't use it in production code. So Java
offers a safer solution.
However in Java you are stuck
with the GC system and there's no way to automate the detection of
zombies (big assumption here by someone who's never used it).
You can detect them just as easily as in C++. The big
difference is that you don't need external instrumentation that
makes the detection too slow to be used in production code.
In principle it should be possible to pick up all potential
zombies/dangling pointers in C++ by using a sufficiently clever
debugging allocator.
I think some systems do this. The trick is to not make the
memory available for re-allocation as long as there is a pointer
to it still in existance, mark it as freed somehow, and then
instrument every single pointer dereference to check for the
mark. (It still misses dangling pointers to on stack objects,
of course.) The problem is that it has unacceptable runtime
cost; the standard C++ model requires that all objects have
explicit lifetimes, even when the design doesn't require it, so
you have to check every single pointer dereference, and not just
those where the object by design has a determinate lifetime.
And if you think of things like the implementation of a string
class, you'll realize that there are a lot of objects which,
like the char array in a string, don't need explicit lifetime.
The essential thing in being able to detect the problem, of
course, is not allowing memory to be reused as long as there is
still an existing pointer to it. Garbage collection, in sum.
(The Boehm collector is often used in this way, as a leak
detector, and, with additional instrumentation in user code, to
detect dangling pointers.)
Admittedly this doesn't stop you assigning duff
values to pointers, but that's the price you have to pay for using a
system-level language.
There are several issues at stake. The fact that you can have
an uninitialized pointer, with undefined contents, can hardly be
considered a feature.
If I was going to tighten up C++ one of the first things I'd do is
insist on a defined order of evaluation of function arguments and I
wouldn't be averse to the automatic initialisation of variables (as in
D).
Agreed there. These points are even more important than garbage
collection. On the other hand, there seems to be a great deal
of resistence in certain circles against them. More, even, that
for garbage collection. (Perhaps the reason is that garbage
collection has always been proposed as "optional"---you don't
have to use it.)
After all, a compiler could always provide switches to turn these
off for performance freaks who know what they're doing.
"Performance freaks"... "know what they're doing". Sounds like
an oxymoron to me.
--
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! ]