Re: [boost] [smart_ptr] questions about some regression test cases

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-04-29 09:43:07

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 29 April 2008 02:18 am, Daniel Frey wrote:
> I think there are cases not caught by the current assert condition:
>
> struct A : boost::enable_shared_from_this<A> {};
>
> int main()
> {
>   boost::shared_ptr<A> pa;
>   {
>     A a;
>     pa = a.shared_from_this();
>     boost::shared_ptr<A> pa2( &a );
>     // here, first 'pa2' and then 'a' goes out of scope!
>   }
>   // now 'pa' still exists and points to a deleted object
> }

You've already created undefined behavior just by passing ownership of a stack 
object to a shared_ptr with the default deleter, which is in no way specific 
to enable_shared_from_this.

> What do you think of the following condition:
>
> BOOST_ASSERT( _weak_count.use_count() == 0 ||
>               _shared_count.use_count() == 1 );

There is no shared_ptr requirement that a user is forbidden to create dangling 
shared_ptr if they choose to.  I don't think owning an 
enable_shared_from_this derived object should impose any additional 
constraints on shared_ptr usage.

Adding additional checks to enforce shared_ptr best practices seems like an 
independent concern from esft.  It could be done in an independent class, and 
might make decent example for sp_accept_owner usage.

- -- 
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIFyXs5vihyNWuA4URAn3RAKCT385xl5617h1uE+OmqrsItL6TdgCdGPW1
Tg6I9VXEsRVxQrLVFYQuCIM=
=7whB
-----END PGP SIGNATURE-----