Re: What C++0x features are relevant to you?

I do not understand why requiring the usage of std::function to take
lambdas in non-generic functions makes lambdas "less cool"... The only
overhead that it has it that it might use the heap, but you would need
that too in any implementation of lambdas where there is a unified type
defined for them.

Note that every diferent lambda needs different amount of space to store
the closure. In C++ every type with value semantics should be able to be
stored on the stack, and for that you need to know the exact size that
you need to store values of that type. [1] That is why we allow the
compiler to define an unknown but determined (reminds me of quantum
physics :p) type, that you can still infer with auto for locally stored
lambdas, or pass as a template argument. If you want to treat them
generally in non-generic-code you have to use std::function, and the you
pay for the overhead of having the closure in the heap, as you would for
every other language supporting lambdas. Actually I personally find the
way lambdas are implemented in C++ very clever, because this still
allows the use of stack-based closures very efficiently thanks to
generic programming, while having all the power that it would have in
other more functional languages thanks to type erasure :D

JP

[1] To put this in a different way:

int v = 10;
auto l = [&v] (int a) { std::cout << v << a; }

Is the same as C++98:

struct my_lambda
{
   int& v_;
   my_lambda (int& v) : v_ (v) {}
   void operator (int a) { std::cout << v_ << a; }
};
int v = 10;
my_lambda l (v);

As you can see, there is no way to define a general functor my_lambda
for all the different closures that you would have to store in different
contextes... unless you do at compiler level the kind of thing that
std::function correctly does at library level already :D

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]