Re: [boost] ScopeExit

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2007-08-21 10:44:01

On 8/21/07, Mathias Gaunard <mathias.gaunard_at_[hidden]> wrote:
> [...]
> Another issue is that bind often prevents the compiler to inline the code.
> For example,
>
> [long code snipped]
>
> The first call won't be inlined with GCC, while the second call will.
> The first call is similar to what boost.bind generates.
> Note that LLVM is capable of inlining both.
>

BTW, this is considered a bug in the GCC optimizer (gcc is perfectly
capable to find
out that the address is a constant, it simply doesn't run the inliner
after constant propagation. There was a bugzilla entry about that, but
I do not know if anybody did fix it yet).

>
> > 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.
>
> Lambda expressions will probably be built-in in the next standard
> anyway. Better work on implementing that in GCC.
>

Well, writing a ScopeExit like macro will take *far* less time than
implementing lambdas in gcc. Especially if, like me, you know nothing
of gcc internals and have no compiler experience. (BTW, the last
lambda proposal looks very good)

> However, it could be useful to try to provide overloaded operator. using
> macros, and thus to allow to replace boost::bind by something better.
>

This should be much easier.

gpd