Boost logo

Boost :

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
> This can be handled fairly neatly by supplying a release() method.
This has
> already been proposed for linked_ptr; it could easily be incorporated
> 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
> Supplying explicit methods to convert to other known smart pointers
> release_as_auto_ptr) would be largely redundant, since most (all?)
> 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

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.



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