[boost] Re: Re: Re: Re: Garbage Collection, Reference Count orOwnership?

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-10-08 09:52:39

Peter Dimov wrote:
> Philippe A. Bouchard wrote:
>> Gregory Colvin wrote:
>>
>>> My suspicion is that your implementation of garbage collection can
>>> be given a shared_ptr interface with no loss of performance, which I
>>> would prefer over introducing a new type.
>>
>> I agree, but I would like the new interface of shared_ptr to be able
>> to handle pure garbage collectors... it is true that sometimes pure
>> garbage collectors are faster than reference counts.  That will cover
>> every possible smart pointer.
>
> Is there something in the shared_ptr specification that makes your
> implementation impossible?

Not impossible but complex:
- the members of shifted_ptr are not the same as shared_ptr;
- the pointee is different, therefore casts between different smart pointer
types will have to reconstruct a new object;

I was thinking that maybe every smart pointer types could be created with
your design:
- a normal smart pointer using standard operator new (as shared_ptr is);
- a policy that removes reference counts and uses pure garbage collection;
- a policy that mixes garbage collection with reference counts;
- a policy that adds an "indicator *", therefore incrementing the size of
smart_ptr by sizeof(void *);
- a policy that compresses the actual shared_ptr into the actual shifted_ptr
(but requiring an object factory).

So:
- it could defaults to "standard operator new / rc / no gc / no indicator *
/ no compression" (as shared_ptr is right now);
- if you want to accelerate the project again then "standard operator new /
no rc / gc / no indicator * / no compression" (standard raw pointer);
- if you want your destructor to be called on time and accelerate the
project you could use "object factory / rc / no gc / indicator * /
compression" (as shifted_ptr is right now).

Notes:
- the last combination wouldn't be that much slower than the latter;
- other possible combinations wouldn't be optimized for a specific ressource
usage;
- it sounds easy to mention its architecture, but implicit casts would still
be difficult to implement.
- is there a book I could read about latest smart pointer designs? ;)

Philippe