Re: [boost] [smart_ptr] enable_shared_from_this enhancement

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-03-17 13:29:44

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

On Monday 17 March 2008 12:38 pm, Peter Dimov wrote:
> Interesting idea. I'm not sure why do you need the two pointers though.

In the last version I posted, the second shared_ptr stores the user's deleter.  
I didn't see any other way to get the user's deleter into the shared_count 
for the shared_ptrs already constructed from internal_shared.  I imagine the 
implementation could be trimmed down a bit by using classes internal to 
shared_ptr's implementation, but I'm most familiar with the external 
shared_ptr api so I stuck to that.  One additional gotcha I thought of, is 
the internal_shared pointer would need to use a special constructor to avoid 
triggering the enable_shared_from_this machinery when it is constructed.

> How would you cope with the following scenarios:
>
> class X: enable_shared_from_this<X> {};
>
> int main()
> {
>     { X x; }
>     { std::auto_ptr<X> px( new X ); }
> }
>
> ?

In cases where an X object is never owned by a shared_ptr, the shared_ptrs 
from shared_from_this() would effectively have a null deleter.  If people 
were using shared_from_this() to test if the object ever really got its 
ownership passed to a shared_ptr, that code would break.  That functionality 
could be replaced by a query returning a bool that indicated if the 
enable_shared_from_this object has been owned by a shared_ptr constructor 
yet.

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

iD8DBQFH3qqJ5vihyNWuA4URAi8UAJ41Pu+dyJbvY0/LGaNfYqQkjAL3gwCgvYVs
27HkOTI3gt/WAif2yQRlto8=
=8SV8
-----END PGP SIGNATURE-----