From: Andrey Semashev (andysem_at_[hidden])
Date: 2005-08-22 14:16:02
"Pavel Vozenilek" <pavel_vozenilek_at_[hidden]> wrote in message
> "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
> 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
- 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:
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.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk