Re: detecting stack unwinding
restor wrote:
Of course using a macro already suggests that we are missing something
in the language, and, as usually with macros, unexpected things can
happen like in:
yeah, it would be much simpler if the interface of original transaction
class was enriched with explicit "commit" (and preferably "rollback")
functions. We could simply write (on the lap):
class transaction_owner
{ // all private
~transaction_owner() {}
virtual void begin_transaction() = 0;
virtual void commit_transaction() = 0;
// following is no-op if already commited and never throws
virtual void rollback_transaction() = 0;
friend class transaction; // to improve encapsulation
};
class transaction : boost::noncopyable
{
transaction_owner& to_;
public:
explicit transaction(transaction_owner& to) : to_(to)
{to_.begin_transaction();}
void commit() {to_.commit_transaction();}
void rollback() (to_.rollback_transaction();}
~transaction() {to_.rollback_transaction();}
};
class connection : public transaction_owner
, public boost::noncopyable
{
virtual void begin_transaction();
virtual void commit_transaction();
virtual void rollback_transaction();
// . . .
};
connection& conn = // . . .
transaction t(conn);
conn.execute(statement1);
conn.execute(statement2);
t.commit();
.. and above will work in all situations, including nested loops or
inside destructor called during stack unwinding.
B.
--
Remove -trap- when replying. Usun -trap- gdy odpisujesz.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]