[Gc] Changes to gc_allocator.h
ben.hutchings at businesswebsoftware.com
Wed Aug 18 07:28:43 PDT 2004
David Jones <dej at inode.org> wrote:
> On August 17, 2004 01:25 pm, Ben Hutchings wrote:
> > I changed destroy() to clear the memory of the destroyed object if
> > it is not known to be pointer-free. This is important because
> > containers can destroy elements without freeing the memory they
> > live in; this is particularly true of std::vector. Unless the
> > memory is cleared this can result in excessive retention of memory.
> > Unfortunately the standard does not require containers to call the
> > allocator's destroy() member so this doesn't help everywhere.
> One thing I did in my code base is to create a pseudo-smart pointer
> GCPtr<T> which is basically a wrapper around a T* but with the
> following features:
> GCPtr<T>() initializes the wrapped pointer to NULL.
> ~GCPtr<T>() clears the wrapped pointer.
> If you have a vector of these things, then the vector is required
> to call the destructor for each element (no matter what allocator
> is used) so this should solve THAT problem.
I see that that's a more reliable solution if you have a vector of
pointers. I was also concerned with vectors of user-defined objects
that contain pointers or references. Of course with user-defined
types one can make the destructors clear pointer members but this
doesn't work for const pointers or references or for "user-defined"
types from libraries that it is impractical to modify.
> Also, this solution works to clean the stack of decommissioned
> pointers as well.
If your compiler's optimiser is any good it will determine that
there is no need to write to a pointer that can never be read back
(within standard C++) so this won't work.
More information about the Gc