Boost logo

Boost :

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
> 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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at