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

From: Miki Jovanovic (miki_at_[hidden])
Date: 2000-03-03 12:21:55

"gavin collings" <gcolling-_at_[hidden]> wrote: 
> Currently, it can't be done
> using shared_ptr, with release() it can
> 
>    void otherFunc( shared_ptr<myClass> sp_myclass )
>    {
>       auto_ptr ap( sp_myclass.get() );     // no good  - two owners
>       auto_ptr ap( sp_myclass.release() ); // or.. maybe ok - as above
> 
>       lib_func( ap );
>    }
> 
> IMO, if a programmer *needs* to call lib_func, not allowing a him to
do so means
> he's going to find some work around using raw pointers anyway, and is
more
> likely to be put off by the smart pointer approach.  Better to let
him take the
> risk?
>  
> But, going on to the proxy class approach, otherFunc could declare
itself as
> 
>    void otherFunc( shared_ptr_sink_proxy<myClass> spp_myclass )
>    {
>       auto_ptr ap( spp_myclass ); // conversion invoked
>       lib_func( ap );
>    }

Hi Gavin,

It is me again. If I was not clear in my first example, I will use
yours. In both of your examples, the program would GPF. Why. Reason is
quite simple. The function parameter is a value parameter, that means
it took a copy of the callers data. This means two shared_ptr's. The
one in the function is released, and auto_ptr will then delete the
object. But when the function returns, the original shared_ptr that was
passed as the parameter will want to destroy the object as well. Boom!

If we implemented release() to clear pointers of all related
shard_ptr's, that would change semantics of the shared_ptr as a whole,
and that is probably not a good idea.

I hope I was clearer this time.

Cheers,

Miki.