Re: Garbage collection in C++
On Nov 20, 5:13 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
On Nov 19, 5:31 am, James Kanze <james.ka...@gmail.com> wrote:
[...]
This is a case where garbage collection is necessary for
maximum robustness. But it obviously doesn't solve
everything. You can still dangle pointers to local objects,
and a rogue pointer can still overwrite anything. In the
end, the real question is how much undefined behavior can
you accept; in my experience, undefined behavior is a sure
recepe for reduced robustness. And garbage collection
removes one (and regretfully only one) potential source of
undefined behavior.
Thank you. I understand your point much more clearly now. And
as far as I can see you are right. GC does enable more
advanced error detection.
That said, "[setting] whatever bits you need" and "testing
them with each use of the object" was discussed with respect
to zombies in the referenced thread. The concern is that such
bits and checks cost both space and time (at least for
non-virtual functions and member variable access). Do you
agree this is a real cost and a legitimate concern? Or is
there a clever way around those costs?
As they say, there's no such thing as a free lunch. In most
specific cases, I think you will be able to come up with some
solution which doesn't entail any extra space associated with
the object; classes with no redundancy and no extra bits are
rare. And often (but certainly not always) you should be able
to trick hardware into making the check (set a pointer to an
invalid value, for example). But even in these cases, you have
the extra space overhead associated with garbage collection, and
you have created extra work for the programmer. If the compiler
were to take charge of this, the extra space associated with the
object would be systematic, but it could presumably somehow be
integrated into the overall overhead of memory management. (In
all of the manual memory management schemes I've seen, you have
at least one extra pointer per allocated block. Which must be a
multiple of 4 or 8, depending on the machine, so you have 2 or 3
free bits to play with. If you're the compiler or the library
implementer; you can't reasonably get at them from user code.)
On the other hand, unless the compiler was very, very smart (and
I'm not aware of any research having been done on ways to
optimize this), you'd have a systematic runtime overhead.
In practice, in all of the cases I'm aware of where a dangling
pointer was used to breech security, the technique used was to
cause the vptr to be overwritten in a way which caused the
malicious code to be executed when a virtual function was called
through the dangling pointer. I'm not aware of a security
problem which doesn't involve pointers to functions somewhere,
so just zapping all of the memory with values that would be
invalid as pointers (and ensuring that it doesn't get reused as
long as there is a pointer to it) would be sufficient. If the
goal is larger; to detect as many possible programming errors as
possible, as soon as possible, then more effort would be
involved.
As an aside, it seems that the simple
constructor/destructor paradigm has proven to be extremely
flexible in implementing a variety of resource management
solutions. Do you agree?
More or less. The destructor paradigm certainly rates as
one of C++'s successes, and IMHO, beats finally hands down.
Which doesn't mean that finally wouldn't be nice as well.
Nothing wrong with having a choice. (I'd actually like to
see a way of creating "destructors" ad hoc. Something along
the lines of:
cleanup { code } ;
, which would basically create an anonymous variable whose
destructor executes the code.
Indeed. Anonymous destructors would provide for cleaner
syntax. However, since they are already supported with more
verbosity
void foo ( ) {
struct anon {
~anon ( ) {
std::cout << "(zombie) : brains! brains!\n" ;
}
} a ;
}
perhaps many would considered them to be only "sugar". On the
other hand lambda expressions are in this sense also "sugar"
and they were accepted into C++0x.
Exactly. The current support becomes a lot more awkward if the
cleanup code needs to access local variables.
Time constraints have meant that I haven't been active in the
lambda proposal that was adopted. I regret this, because I had
definite ideas about it---IMHO, at the base, what we need is
anonymous classes (or lambda classes, the name isn't important);
constructs which, conceptually, implicitly define a class with
protected references to all of the accessible local variables
and create an instance of it with all of the references
initialized. (Obviously, I expect the compiler to "optimize"
the references out in the generated code.) A lambda function
would be nothing more than a functional object which derived
from such a class; a lambda expression would wrap the expression
in a lambda function, then generate the object. Cleanup, above
would be derived from the class as well, except that the code
would define the destructor, rather than an operator()(). And
I'd expect the class itself to be available, so that the
programmer could derive from it and add additional state, if he
wanted.
I've not studied the lambda proposition in detail, so I don't
know how much of the above it might incorporate. A quick
glance, however, does show that it involves a "closure object",
which sounds very much like the instance of my anonymous class
(although described in somewhat different language). So it
shouldn't be too hard to add "cleanup" as an extension, or in a
later version of the standard, if someone can find time to write
up a proposal for it.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34