On 8/21/07, Mathias Gaunard <mathias.gaunard@etu.u-bordeaux1.fr> 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