[scope_guard] New version consideration
I've made some reworks and additions to my previously presented version of generalized scope guards. To be short, here are brief changes: - Scope guard creation has moved to make_* functions instead of explicitly creating a scope guard object. - Now not using the Boost.Function to hold functors. The functor type is detected in make_* creating functions. This gave a considerable perfomance gain especially in simple tests where guard creation/destruction takes large amount of the time comparing to the useful work. - Unified scope guard variable declaration, regardless of the type of the guard (destruction guard or construction/destruction guard). In fact only a reference to a base class is declared, so it may be bound to any type of guards returned by the make_* function. As a result users' code shall be simplier. - Several internal changes, including BOOST_NO_EXCEPTIONS awareness, Boost.Preprocessor usage instead of self-made analogues and others. - Basic transactions support. Actually, the construction/destruction guards are created by make_transaction function, so the construction functor has the semantic of action, and the destruction functor - of rollback or undo action. Disarming such guard has the semantic of committing actions. - Added a simple actions trace class (in a separate file). It can be used with scope guards to perform complex transactions. In other words, when executing a complex action that consists of several discardable subactions this trace class allows to massively commit or rollback these subactions. I've tested this version with VC 7.1, ICL 9.0 and GCC 3.4.4 (MinGW version). The sources with some instructions (in .h-files) and a small test, which may be used as an example, are in the Sandbox: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=scope_guard.zip&directory=& A few word of what I'm not sure of: - The naming of classes/functions/macroses. They look quite simple to me, but maybe someone has better proposals? Especially it concerns macroses (may be some prefixes?). - It would be great if someone tried it on some other compilers - VC 6, for example. It should work, but I don't have the compiler to be sure. - Is there still interest in this implementation or the multi_index version is finally chosen to be Boost.ScopeGuard? PS: I'm really sorry for such a long delay. I was rather busy for last few weeks.
On 9/4/05, Andrey Semashev <andysem@mail.ru> wrote:
A few word of what I'm not sure of: - The naming of classes/functions/macroses. They look quite simple to me, but maybe someone has better proposals? Especially it concerns macroses (may be some prefixes?).
For what I know, the macros should be prefixed with BOOST. And more important, shouldnt at all start or have __. I didnt liked very much of the names Invoker and Functor, I dont think they mean very much, mainly when used side by side... after all, isnt Invoker a functor too? Shouldnt the "CHandler" use operator() insted of on_exception? I think it would make it more generic. Best regards, Felipe. -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
Felipe Magno de Almeida wrote:
On 9/4/05, Andrey Semashev <andysem@mail.ru> wrote:
A few word of what I'm not sure of: - The naming of classes/functions/macroses. They look quite simple to me, but maybe someone has better proposals? Especially it concerns macroses (may be some prefixes?).
For what I know, the macros should be prefixed with BOOST. And more important, shouldnt at all start or have __.
Yes, I've been told about this. These and some other cosmetic changes will be applied in the next version.
I didnt liked very much of the names Invoker and Functor, I dont think they mean very much, mainly when used side by side... after all, isnt Invoker a functor too?
They Invoker and Functor have different semantic. The first makes some pre- and postarrangements (like catching exceptions, as with_catcher does), and the second does the useful job. While the first one is a policy (wich can be user-defined) and can be applied to invoke many different functors, the second one is not even necessarilly written by you (it may be an API call, for example). Getting rid of Invoker policy will eventually lead you to hand-made analogues.
Shouldnt the "CHandler" use operator() insted of on_exception? I think it would make it more generic.
The "CHandler" isn't necessarilly an object class. It might be an abstract interface, for example. And making an interface of virtual operator()'s isn't very convenient to my mind.
Shouldnt the "CHandler" use operator() insted of on_exception? I think it would make it more generic.
The "CHandler" isn't necessarilly an object class. It might be an abstract interface, for example. And making an interface of virtual operator()'s isn't very convenient to my mind.
But havinng thought of it for a while, you may be right here. At last, a small functor-like adaptor may be made to deal with interfaces. I shall change it in the next version.
participants (2)
-
Andrey Semashev -
Felipe Magno de Almeida