Boost logo

Boost :

From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2007-08-21 10:29:07

Giovanni Piero Deretta wrote:

> 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.

There is one main issue with lambda: operator. cannot be overloaded.
As a result, one must use bind, which is not only ugly but also requires
you to explicitly write the type of what the placeholders are, which
prevent generic visitation, for example.

Another issue is that bind often prevents the compiler to inline the code.
For example,

#include <cstdio>

struct Foo
     int value;

     void display() const
          std::printf("%d\n", value);

template<typename F>
inline void apply(const F& f)
      Foo foo = {42};

struct functor1
     void (Foo::*f)() const;

     functor1(void (Foo::*f_)() const) : f(f_)

     void operator()(const Foo& foo) const

struct functor2
     void operator()(const Foo& foo) const

int main()

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.

> 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.

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at