[shared_ptr] commit/rolback
Wouldn't it be nice to extend shared_ptr to support transaction-like
semantics? Or is it possible already?
Sometimes it's needed to execute code on exit only until we haven't reached
some point (of "no return"):
{
shared_ptr<void> cr_guard(static_cast
Denis G. Priyomov wrote:
Wouldn't it be nice to extend shared_ptr to support transaction-like semantics? Or is it possible already? Sometimes it's needed to execute code on exit only until we haven't reached some point (of "no return"):
This really is an abuse of shared_ptr. Search this list and the developer list for "scope guard", there was some interesting discussion a few weeks ago. Sebastian Redl
Dear Sirs,
Does anyone have a working example of serialization of shared_ptrs with
non-default deleter and factory construction as described in
http://www.boost.org/libs/smart_ptr/sp_techniques.html#preventing_delete?
The code below (correctly) triggers error in boost/checked_delete.hpp
because the destructor of class X is private.
#include <iostream>
#include <fstream>
#include
The following "blunt instrument" will make things work - though I'm not sure that its not a little tooo crude. That is it will still prevent your destructor from getting called via delete - though it could now be called via checked_delete. Robert Ramey Mikko Vainio wrote:
Dear Sirs,
Does anyone have a working example of serialization of shared_ptrs with non-default deleter and factory construction as described in http://www.boost.org/libs/smart_ptr/sp_techniques.html#preventing_delete?
The code below (correctly) triggers error in boost/checked_delete.hpp because the destructor of class X is private.
#include <iostream> #include <fstream> #include
#include #include #include #include class X { private:
template<class T> friend inline void boost::checked_delete(T * x);
~X();
participants (4)
-
Denis G. Priyomov -
Mikko Vainio -
Robert Ramey -
Sebastian Redl