Boost logo

Boost :

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-07 11:44:06


> From: "Peter Dimov" <pdimov_at_[hidden]>
> From: "William E. Kempf" <wekempf_at_[hidden]>
> > I think that extending it to free memory in cycles would be a great idea.
> Of course, this opens a large can of worms about how to handle destruction
> of objects which refer to each other...<
>
> One possible approach is to return a list of references to the "offending"
> shared_ptr instances to the user, who can then reset() them as appropriate.
> Actually it's not as simple as that since a reset() can invalidate some of
> the returned references; the shared_ptr instances would first need to be
> copied to a temporary container, the originals reset(), and the temporary
> container destroyed, but the general idea is the same.

This just pushes the issue off on the end user... who may not be any more capable of dealing with the problem either. If he can't do a lot of book keeping to handle the circular problem, then pushing it off on him is not much help. And if he can do the book keeping, there's probably a solution he can code into the destructors themselves.

I don't know what the real answer is (if there is one), but personally I can live with this case simply being undefined behavior, since it can often (usually?) be avoided in the first place.
 
> > I think that full GC is one of the major things missing from the C++
> language, and the appeal of a smart pointer approach, where I pay for GC
> only when I want/need it, is a great idea.<
>
> Making a real "zero overhead" collector is a bit harder, and I'm not sure I
> have the time to do it.

Yep. I thought you were volunteering, though, from your post and question ;).
 
> An additional requirement is to be able to discover shared_ptr subobjects
> and to distinguish a shared_ptr from a weak_ptr; I've used a "magic
> constant" but this increases sizeof(shared/weak_ptr) from 8 to 12 on a
> typical implementation. It is possible to "mangle" the object pointer (by
> XOR-ing it, for example) in weak_ptr and replace the magic constant test
> with a valid pointer test, but I'm not sure whether this is a good idea. :-)

Yep... a GC smart pointer is a non-trivial task. It would probably be best to make it a seperate smart pointer, so as not to impact usage of the ref-counted shared_ptr. I know that this topic has been brought up numerous times, but I do think it would be very beneficial for someone to submit a quality GC smart pointer to Boost.
 

William E. Kempf
wekempf_at_[hidden]


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk