Is it bad that C ++ 0x lambda expressions do not have a named type?

Recently I read a little about lambda expressions on the Internet, and it seems to me that in C ++ 0x lambda expressions there will not be any type (or types) that will be associated exclusively with lambda expressions - in other words, lambda expressions will match the template arguments or auto arguments / variables. What happens as described here is that

Compilers that support lambdas will create a unique anonymous functor type for each lambda expression

My question is, is this bad? It makes no sense to have some kind of keyword that matches only lambda expressions, for example. lambda which will work as follows

 void f(std::function<int(int)> func) { func(2); } template<typename T> void g(T func) { func(2); } void h(lambda func) { func(2); } int main() { int fpointer(int); struct { int operator()(int var) { return var; } } functor; f(fpointer); //ok (actually a linker error, but for the sake of example) f(functor); //ok f([](int var) { return var; }); //ok g(fpointer); //ok g(functor); //ok g([](int var) { return var; }); //ok h(fpointer); //error -- function pointer isn't a lambda expr h(functor); //error -- functor isn't a lambda expr h([](int var) { return var; }); //ok return 0; } 

Honestly, I really don't see the usefulness of this (especially considering that auto accepts lambda expressions, so then you could assign a lambda to a variable), but it still doesn’t sit right with me that lambda expressions are anonymous types and cannot be associated specifically with only one specific type (with the exception of all others).

In essence, my question is whether it is good that lambda expressions are anonymous (both in terms of utility), and the lack of a lambda type robs us of any functionality - and philosophically - does this really make lambda expressions always have "type" auto )?

+6
c ++ lambda c ++ 11
source share
2 answers

Lambdas are independent types. The code

 void h(lambda func) { func(2); } 

makes no sense because lambdas do not have run-time polymorphism. Recall that lambda is equivalent

 struct unique_name { return_type operator()(Arg1 a1, Arg2 a2, ... , Argn an) { code_inside_lambda; } } 

This is a unique type in itself. The above code will be the same as

 void h(class C) { C(2); } 

This also makes no sense, even if we assure that C has operator() . You need a template:

 template<typename T> void g(T func) { func(2); } int main() { g([](int x){return x + 2;}); } 
+11
source share

I see no reason to differentiate function types based on whether the function has a name or not. Lambda functions are simply a shorthand for easily defining a convenient function. Name or absence of a name, the behavior of the function when called is the same.

Think of it this way. An early version of your software has a predicate defined as an anonymous function. Over time, requirements become more complex, and your predicate also becomes more complex - and perhaps you need to call it more than one place. Reasonable task is to reorganize so that you have a named function.

There is no reason why the called function (the one that calls the predicate) should take care of this. Simple or complex, named or anonymous - this is still just a predicate function.

One of the minor issues is closure - I have not tested it, but with some luck C ++ will have nested named functions with closure, as well as lambdas.

+3
source share

All Articles