[Smart Pointers] enable_shared_from_this::shared_from_this() behaviour query
shared_from_this() throws bad_weak_ptr if it's called in a derived destructor even if the object is heap allocated, does anyone know if this is intended? And if so, why? Example: class DestructorCheck : public std::tr1::enable_shared_from_this <DestructorCheck> { public: DestructorCheck() { } ~DestructorCheck() { shared_from_this(); } }; BOOST_AUTO_TEST_CASE(enable_weakTests) { BOOST_CHECK_THROW( { DestructorCheck d; } , std::tr1::bad_weak_ptr ) BOOST_CHECK_NO_THROW( { std::tr1::shared_ptr<DestructorCheck> d = boost::make_shared<DestructorCheck>(); } ) }
shared_from_this() throws bad_weak_ptr if it's called in a derived destructor even if the object is heap allocated, does anyone know if this is intended? And if so, why?
What else could it do? if the dtor is running the refcount has reached zero... and, well, you know, the dtor is running. If you created a shared_ptr to that object - what would happen when that new shared_ptr went out of scope? The refcount would reach zero (again) & the object would be double deleted. What semantics were you expecting?
On 13 June 2011 06:29, David Blaikie
shared_from_this() throws bad_weak_ptr if it's called in a derived
destructor even if the object is heap allocated, does anyone know if this is intended? And if so, why?
What else could it do? if the dtor is running the refcount has reached zero... and, well, you know, the dtor is running.
If you created a shared_ptr to that object - what would happen when that new shared_ptr went out of scope? The refcount would reach zero (again) & the object would be double deleted.
It's possible to create smart_pointers with null deleters though that in itself doesn't solve my problem.
What semantics were you expecting?
The problem I was facing involved a cyclic data structure (two way references) and was implemented using weak_ptrs. When an object was deleted it was necessary to notify its referers of its deletion which I was looking to do using a weak_ptr. However, I then realised that although weak_ptrs are great, they are not useful at destruction time due to the fact that there is no smart_pointer remaining with which they are validated, so I have re-implemented using raw-pointers. It's hit upon a major semantic difference between smart pointers and raw pointers. I suspect that it may be possible to implement a smart pointer system that could actually continue to correctly mask pointers during deletion (perhaps by deleting the managed object just before the last remaining shared_ptr internals are destroyed).
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
David Blaikie -
eddyaod＠gmail.com