Re: [boost] Purpose adding a scope guard classes to the Boostlibrary

From: Andrey Semashev (andysem_at_[hidden])
Date: 2005-08-22 14:16:02

"Pavel Vozenilek" <pavel_vozenilek_at_[hidden]> wrote in message 
news:deb674$oa0$1_at_sea.gmane.org...
>
> "Andrey Semashev" wrote:
>
>> I purpose to add a generalized scope guard classes to the Boost library. 
>> I have a rather simple but flexible implementation of such classes (I've 
>> attached the sources). Since I'm new here, I don't really know if they 
>> conform some source code conventions in Boost (if any), but if they 
>> don't - please, let me know.
>>
>
> I was not able to extract the code (could you add
> it as attachment or put it into Sandbox?) but FYI:

Actually, I tried to attach it to my first posting, sadly, unsuccessfully. I 
tried once more in my reply to David, it should be okay this time.

> One ScopeGuard implementation (practically copy
> of Alexandrescu's one) exists inside Multi-Index library
> (boost/multi_index/detail/scope_guard.hpp).
>
> It was intended as "temporary" solution
> "until someone creates full-features Boost library".

Yes, I've considered the multi_index (Alexandrescu) version and the main 
purposes I've opened this thread are:
- The multi_index version is in "detail" area, so a user cannot safely use 
it. Theoretically speaking, it may be modified or even removed in future 
versions.
- The implementation I described has some advantages comparing to 
multi_index one (namely, exception handling support and construction functor 
execution). In a simpliest case it is rather similar to multi_index one.

On the other hand, the advantage of the multi_index version is emulating 
bind/mem_fn functions for several functor arguments and a possibility of not 
using boost::funcion, which gives some perfomance gain. To my mind, it might 
be better to make a mixed solution, with blended functionality and 
optimization. The only nasty thing will be excessive template parameters 
number (the drawback I tried to avoid when I was designing my version).

> A very interesting Scope Guard variant can
> be found in TnFox library:
> http://tnfox.sourceforge.net/TnFOX/html/group__rollbacks.html

Yes, a rather interesting guards application. But from that point if view 
scope guards are not simply scope guards but a transaction support 
mechanism. Speaking frankly, I haven't thought of it that way yet. Anyway, 
such mechanism may be done with entering-and-leaving scope guard. And guard 
collections is another god idea.

> /Pavel
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>