Re: [boost] shared_ptr doubts

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-01-30 05:29:16

Don G wrote:

[...]

> The std containers offer what is needed to accomplish a well focused
> task, allocating only the data necessary for that job and no more.
> For example std::list need only allocate 2 pointers per object. If
> Stepanov had gone on to add feature after feature that made this
> number on par with shared_ptr, again, it likely would not have been
> well received.

... and ...

> I am focused on the last statement above. As it sits, shared_ptr
> simply goes too far and in so doing one must always ask "is
> shared_ptr suitable in this case?" As a library author, this is often
> an impossible question to answer, because it could depend on the use
> to which the library is put. In other words, by adding all the
> frills, shared_ptr actually reduces its scope of applicability.

... and ...

> "WARNING: shared_ptr may allocate 40+ bytes per object (fine print:
> depending on platform and multithread considerations, your mileage
> may vary, etc.)"

shared_ptr only contains the features that are absolutely essential for the 
answer of "is shared_ptr suitable" to be "yes" in the vast majority of cases 
(and to stay "yes" as the design evolves). A not so small number of extra 
features that do not contribute significantly to its expressive power have 
been rejected.

I suspect that you haven't had much experience with the design possibilities 
opened by weak pointers or custom deleters, which might be why you don't 
want to pay 40+ bytes for them. For me, they are easily worth double this 
cost.

That said, Alexander Terekhov has discovered a lock-free algorithm that 
implements the reference counting required by shared_ptr, so this brings 
down the design-imposed overhead to four words per object for an empty 
deleter. You can find a prototype implementation at

http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp

I will try to portabilify this implementation and incorporate it in the next 
Boost release.

You are absolutely correct that sometimes you can get away with a simpler 
smart pointer that carries less overhead. The emphasis in shared_ptr's case 
is on correctness and expressive power over efficiency, because (IMO) the 
first two provide more value in a standard smart pointer, since they are 
much more harder to reinvent. The good thing is that once you have a stable 
design, efficiency usually follows, as happened here.