When to use functors over lambdas

A lambda is a functor – just defined with a shorter syntax.

The problem is that this syntax is limited. It doesn’t always allow you to solve a problem in the most efficient and flexible way – or at all. Until C++14, the operator() couldn’t even be a template.

Furthermore, a lambda has exactly one operator(). You can’t provide several overloads to distinguish between, say, the types of the arguments:

struct MyComparator
{
    bool operator()( int a, int b ) const {return a < b;}
    bool operator()( float a, float b ) const {return /*Some maths here*/;}
};

.. or value category of the object argument (that is, the closure object that is called). You can also not define special member functions, including constructors and destructors – what if a functor shall be responsible for resources?

Another problem with lambdas is that they cannot be recursive. Of course, normal functions (including operator functions) can be.

Also consider that lambdas are unhandy to use as comparators for associative containers or deleters for smart pointers: You can’t directly pass the closure type as a template argument and need to construct the containers member from another closure object. (Closure types don’t have a default constructor!). For a block-scope map that isn’t too much of a hassle:

auto l = [val] (int a, int b) {return val*a < b;};
std::map<int, int, decltype(l)> map(l);

Now, what happens if your map is a data member? What template argument, what initializer in the constructors initialization list? You’d have to use another static data member – but since you have to define it outside the classes definition that is arguably ugly.

To sum up: Lambdas aren’t useful for more complex scenarios because they weren’t made for them. They provide a short and concise way of creating simple function objects for correspondingly simple situations.

Leave a Comment