Re: [boost] shared_xxx issues

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-09-01 12:23:03

From: David Abrahams <david.abrahams_at_[hidden]>
> First Issue:
> 
> I've just found myself wanting a really flexible smart pointer, along the
> lines of the one in Loki by Andrei Alexandrescu. For a long time I thought
> that I would rarely want more than shared_ptr, but I can see that this is
> going to come up again and again for me. Unfortunately, I couldn't use
> Andrei's design because very few compilers will apply the empty base
> optimization in cases of multiple inheritance. So, even if shared_ptr is our
> choice for submission to the committee I would really like to see a
> policy-based smart pointer in boost.

Which policies is it that you want?

> Second Issue:
> 
> I found the following code in shared_array (and I assume the analogous code
> is in shared_ptr):
> 
>         void reset(T* p=0)
>         {
>             if ( px == p ) return;  // fix: self-assignment safe
> 
> What this does is to make a silent success of resetting a shared_ptr with
> the pointer it owns. The problem with that is that resetting a shared_ptr to
> any /other/ pointer which is managed by a shared_ptr is a fatal (and
> hard-to-detect) error, which happens even to experienced programmers. I
> don't think the trade-off is a good one. Making this special case (which we
> can detect) silently work when all other cases will fail without complaint
> is a mistake. I'd rather see an assert() here.

Of course the problem with an assert() is that it only detects
this one easy case, a harmless one, and misses the hard and truly
dangerous cases, and thus might lead to a false sense of security.
It is possible of course to maintain a list or set of pointers
to all shared objects and assert that p is not in the set of shared
objects, as my cyclic_ptr experiment did.

As a general rule any use of the raw pointer functions of shared_.*
should be hidden away from ordinary use behind a create/recreate
interface.  I would be happy to deprecate all these functions
if suitable replacements could be found.