[boost] Re: new approach to smart ptrs -- no new()s is good n ews

From: Gavin Collings (gcollings_at_[hidden])
Date: 2000-01-28 15:15:56

> > -  I set the "unique" pointer values to point to self to avoid null
> > tests
> 
> I'm not sure I understand this. Can you elaborate?
> Would there need to be additional code to check for circular
> references?

I can't remember the exact reasoning - I'll have to dig out the code on
Monday - but I think that the overall I found it more efficient to
initialise the left / right pointers to "this" rather than 0.  You're
right though, certain tests do equate to "if ( left == this )".

> I am feeling a bit sleepy after a big lunch

Sweet dreams.

> > -  I have the list pointers as mutable to reflect the fact 
> > that they may
> > be changed by other objects.
> 
> I have waffled back and forth whether I want copies/assignments to
> take const or non-const references.
> My current feeling is to use non-const, since there could be
> synchronization repurcussions long after the operation completes. 
> But I have barely won this argument with myself, so I don't expect
> anyone else to be terribly swayed.

I meant mutable (as in the keyword) although I have to admit to
dithering on this also.

> I thought size didn't matter :(
> 
> I'm not sure why the number of objects should affect an individual
> operation's speed.  A particular linked_ptr object only communicates
> with its 2 closest neighbors. So adding or releasing references
> should be constant complexity.

Right.

> Likewise, for a shared_ptr, individual operations should be constant
> complexity.

Not so here.  For shared_ptr there is a big asymmetry between the first
operation (that which allocates the reference count) and subsequent
sharing operations (assignment / copy construction) which purely copy
pointers.  In fact, subsequent operations for shared_ptr are faster
since it is smaller.  At some point the smaller size of shared_ptr
outweighs the overhead of its initial allocation - that point is at
around 25-50 sharing operations.  I made a correspondence between
sharing operations and set size in my previous post.

> Can you send me some demo code?

I'll follow up on Monday - I can probably find the timing code too, if
that's of interest.  Is this something that we'd like to see in boost? 
If so, how? - a replacement for shared_ptr or an alternative? (called
linked_ptr?)  I don't mind pitching in a little, my current
implementation already supports the shared_ptr interface.

Gavin.