Re: If GC is the solution, then what is the problem?
Francis Glassborow wrote:
No, you have missed the point. For example a dynamic object with a
trivial destructor (i.e. there is no resource to release) need not be
'deleted', GC will look after the recovery of memory when the last
pointer goes out of scope.
That is just one very simple example. In fact as soon as a dtor is
called an objects lifetime has ended though at that point the resources
will remain allocated until the dtor is exited,
I think the trouble is that you have taken a simplistic statement about
GC (meaning delete does not need to be used) as being what it is or
means.
There is, however a danger now as how will users know which objects
need to have destructors implicitly called on them. Remember
encapsulation - hiding the implementation from the interface.
Now suppose I have my nice efficient vector < T * > instead of vector
<shared_ptr< T > >
because I am taking advantage of gc and want to use the "faster" POD
features of raw pointers.
The danger is - do the Ts need to have their destructors called? What
if T is an abstract base class and its virtual destructor is trivial.
How do I know if the derived classes are trivial or not?
Now we could, of course, introduce some traits to allow the vector to
call something before the items are removed - what it calls depends on
the type it has and whether or not it has ownership. Once we're down
that path though, we are effectively writing a new vector class and can
introduce all this without gc.
It seems we may decide that vector can't call anything on its members
and that we can't use gc on abstract base classes, even though it may
turn out that none of the derivations actually require their
destructors to be called.
(Note: if all the destructor would normally do is delete pointers that
gc can handle, we don't need to worry about them. I'm referring to the
times when destructors need to do some other clean-up. Possibly they
use 3rd party libraries that don't use gc. In any case, we can never be
sure on what derived classes will do).
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]