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