[boost] Re: shared_ptr co-existence with other smart pointers

From: Miki Jovanovic (miki_at_[hidden])
Date: 2000-03-03 10:26:46

"gavin collings" <gcolling-_at_[hidden]> wrote: 
> 2) Accept the need to open up ownership to other shared_ptr
implementations. 
> This can be handled fairly neatly by supplying a release() method. 
This has
> already been proposed for linked_ptr; it could easily be incorporated
into
> shared_ptr.  I'm still in two minds whether it's best to allow this
operation in
> situations where more than one smart pointer is involved (probably
not).
> 
> Supplying explicit methods to convert to other known smart pointers
(e.g.
> release_as_auto_ptr) would be largely redundant, since most (all?)
smart
> pointers will have a constructor taking a raw pointer anyway.

Hi Gavin,

While I am curious if anyone comes up with a suitable implementation of
what you are proposing, I have a major remark. Release() of the kind
you proposed would remove the stored pointer reference from all
instances of the smart pointer. The in this example

  void func( const smart_ptr<myClass>& pMyClass ) {
    if ( pMyClass != NULL ) {
      otherFunc( pMyClass );
      pMyClass->dereference(); // this line is dangerous
    }
  }

In the dereference line, the pointer might be NULL since otherFunc()
might have released it. So introducing release() would change semantics
of all other methods. And this change does not seem to be for the
better.

If you found a way to retain the internal pointer, so the pointer is
left in the smart_ptr but is now in the converted_to smart pointer as
well, that is different. But that does not seem easy at all...

Or, use of release can be restricted to only when refCount in the
smart_ptr is 1. While you seem to imply this restriction, after little
reflection, I am starting to believe that it any non trivial use of the
smart_ptr it will be quite hard to guarantee a refCount of 1.

Cheers,

Miki.