Re: [boost] ScopeExit

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2007-08-20 13:22:39

On 8/20/07, Alexander Nasonov <alnsn_at_[hidden]> wrote:
> Giovanni Piero Deretta <gpderetta <at> gmail.com> writes:
>
> > I use boost lambda expression extensively, and I have a love/hate
> > relationship with
> > them.  When you finally get a (complex) lambda to compile it might
> > even be elegant and even readable, but getting there requires an
> > inordinate amount of time.
>
> :-)
>
> > I do not have time right now for a review (I will try late this
> > evening), but I think that the "inline" lambda capabilities of
> > ScopeExit and its ScopeGuard-like functionality should be decoupled.
> > The trick used by ScopeExit could be much more useful as a generalized
> > (named) closure mechanism. These closures could then be used with the
> > classic ScopeGuard idiom, to emulate what ScopeExit does right now,
> > but could also replace most usages of boost lambda.
> > Anyone would find such a mechanism useful? Alexander, do you think
> > that it would be hard to extend ScopeExit to a generalized closure? I
> > have done some experiments in the past with something like that and it
> > seemed doable.
>
> The problem is that ScopeExit relies on local structs which can't
> be used in templates.
>
> If you look at Implementation section ( http://tinyurl.com/2gerqy )
> you'll notice params_1_t and scope_exit_body_t local structures.
>
> Though, I see how it can be avoided: (void*) new params_1_t(...).
>

Yep, or with virtual functions and a base class templated on the
signature that forwards to the virtual. Tried both of tricks.
Unfortunately gcc isn't capable of inlining either, so it is not very
useful if you need to sqeeze out every bit of performance.

On the other hand, 99% of the time you don't and syntactic sugar is
really nice.

I'll see if I can dig out some old code I have around and upload it in
the vault.

> I should play with this idea. May be I'll be able to come up with
> a good syntax for a generalized closure ;-)
>

yup!

gpd