Lambdas are just classes with operator() overloaded?

Question

The more I read about lambdas the more I hear from people that they are just function objects/functors in disguise (unless they don't capture anything, in which case they're just free static functions. I want to write lambdas at the local scope and pass them to a universal event handler, which calls them as needed, and I'm starting to notice that I can hardly do anything that a traditional function object lets me do. Please let me know if my understanding of this is wrong, as I've commented a whole bunch of stuff you can do with functors and can't with lambdas, as far as I know:

#include <iostream>
#include <vector>

struct MyFunctorClass
{
    // Custom constructor, can't do with lambda
    MyFunctorClass(int& capturedVariable) : capturedVariable(capturedVariable) 
        { std::cout << "I can do anything on construction.\n"; }

    // Overloading constructors, different ways to initialise function object, can't do with lambda
    MyFunctorClass(int& capturedVariable, int sizeOfBuffer) : capturedVariable(capturedVariable) 
        { heapAllocation = new int[sizeOfBuffer]; }

    // Custom destructor, can't do with lambda
    ~MyFunctorClass() { delete[] heapAllocation; }  

    void operator()() { std::cout << "Standard call\n"; }
    void operator()(int arg) { std::cout << "Argument passed: " << arg << '\n'; }   
    // operator() overloading, different ways to call the function object, can't do with lambda

    int* heapAllocation;                // Have heap allocated resources, can't do with lambda
    bool internalStateVariable = true;  // Initialise a member variable on construction, can't do with lambda
    int& capturedVariable;              // I can access this variable directly with MyFunctorClass::capturedVariable = 7, can't do with lambda
};

int main()
{
    int localVar = 0;
    bool trueOrFalse = false;

    {
        MyFunctorClass* myFunctionObj = new MyFunctorClass(localVar, 100);  
        // Can dynamically allocate function object, can't with lambda
        auto lambda = new[&]() { localVar = 1; };   // Can't do?
        lambda.trueOrFalse = true;      // trueOrFalse isn't member of lambda, even though it captured it, doesn't make sense

    }   // Lambda object is destroyed here. My function object lives until I delete it.

    return 0;
}

void holdFunctionObject(MyFunctorClass* funcObj)
{
    static std::vector<MyFunctorClass*> list;
    list.push_back(funcObj);    
    // I can hold all the function objects forever, they'll never go out of scope unless I delete them, can't do with lambda
}

I feel really restricted, it seems like lambdas are just a way of declaring functions "in place". They also hold state, but only can hold state of objects that are already in scope, not create new ones. And also can't be initialised in any specific ways that functors can. Have I got this right? Because they seem VERY different from just a class with overloaded operator();

Answer 1

I don't get what's your point; yes, lambdas are just syntactic sugar for instances of classes with operator() that follow some specific template¹; yes, you cannot do most of the stuff you can do with fully custom classes - and for a good reason: if you want to do that stuff, you can already write a regular class.

Lambdas take a particular, widely employed pattern (throwaway functors that may capture state)² and gives them extremely convenient syntax³. If you need fully fledged classes, the language already have you covered since the mid 70s with the class keyword.

Also, it's important to note that, although lambdas in C++ are implemented in terms of classes, the "view of the world" that underlies the two concepts is different; closures are rooted in functional programming, not in OOP. The idea behind them is to model a single function (=action) along with the data it needs to work that was captured at creation site; an object instead is first and foremost a mutable entity which provides an interface to mutate or query its state. The fact that closures can be implemented in terms of objects and objects can be implemented in terms of closures is interesting and intriguing (and ultimately comes from the fact that both are a combination of state and code that act on it), but they start from quite different grounds. Using one or the other is essentially a matter of understanding whether what you want is primarily code that happens to capture state (a "verb") or is mostly "packaged state" with an interface to mutate it (a "noun").

---

1. This is not just a shortcut to understand their implementation, they are actually specified in these terms in the standard.
2. Pattern that comes from languages where functions and closures were first-class objects from the beginning, thus the resulting syntax sugar helps to write code in style mutated from such languages.
3. Which, let me tell you, is a blessing; having had to port C++11 code to C++03, de-lambdifying code is an exercise in frustration - everything becomes so tediously verbose, and the result "flows" way worse when read. Capturing state is particularly horrible, generally you have to re-state the same thing at least four times - one in the declaration of the field at class level, one in the constructor prototype, one in the initializer list and one in the constructor call. Compare with the lambda capture list.

Answer 2

unless they don't capture anything, in which case they're just free static functions

This is factually incorrect. Capture-less lambdas can be converted into function pointers, but they're not the same thing as a "free static function". They're still objects, while static functions are not (though you can have pointers to functions, that doesn't make functions be objects in the C++ sense of the term).

As for the rest, you seem to not recognize the difference between "all lambdas are functors" and "all functors are lambdas". The former is true, the latter is not, nor is the latter intended to be true.

Lambdas hold their state privately. Hand-written functors hold their state however you want. Most people would consider a functor with publicly accessible state to be bad form, but if that's what you want, that's a decision that's up to you.

By using a lambda, you agree to accept its limitations. The type of a lambda is synthesized at the point of the declaration, and it is not named, so you can't create APIs that accept a specific lambda (well, maybe you can, but you shouldn't). If you want the user to pass a specific functor type, then you should not be using a lambda.

But really... how often do you need the user to pass a specific functor type? Most of the time, what you need is for the user to pass something that can be called with a specific signature. That's what std::function is for. Alternatively, if it is a template function, you can take an arbitrary object that is callable with a specific signature.

And if you really do need the user to pass a specific functor type... so be it. But since most interfaces will not be so restricted, a lambda is an effective solution.

Lambdas are, at their core, syntactic sugar that makes it easy to write common functors. There will certainly be occasions where a lambda just cannot do what you need. But since lambdas cover about 90% of uses for such things, that makes them good enough.

The main purpose of lambdas is to logically put the code for some process adjacent to the place where you're going to invoke that process. This provides locality of the code, relative to what that process is. This is common for callbacks, continuations, and the like.

It also allows such code to access the local scope of the callback easily, compared to a hand-written functor. This makes such processes feel like part of the code, rather than having to track down the definition of the functor type and read its operator() implementation to figure out what's going on.

---

Also:

auto lambda = new[&]() { localVar = 1; };   // Can't do?

You can do this:

auto lambda = new auto([&]() { localVar = 1; });   // Can't do?

Answer 3

There are multiple point you stated that you can't do with a lambda, but in fact you can.

Initialise a member variable on construction, can't do with lambda

Well, since c++14, capture init is a thing:

// internalState is a bool
auto l = [internalState = true] {};

Have heap allocated resources, can't do with lambda

What about these two examples?

// Raw owning pointers are bad, don't do this
auto l1 = [rintptr = new int] {
    // rintptr is a captured pointer, with heap allocated data
    delete rintptr;
};

// Unique pointer is better in every way.
auto l2 = [uptr = std::make_unique<int>()] {
    // uptr is a captured heap allocated int too
};

For custom destructors, it's okay to don't have any. Every captured object should clean themselves automatically. If they don't, create a RAII wrapper that will.

For custom constructor, it cannot imagine a good use case without complicate the lambda further. Keep in mind that lambdas are not meant to replace classes altogether, but to provide an easy way to declare classic functors.

If you really need to execute something when you construct a particular lambda, you can use two lambda instead, one returning another:

auto l = []{
    // Execute what you need before returning the lambda
    // Setup objects to be captured here
    return []{};
}();

Can dynamically allocate function object, can't with lambda

What you need here is std::function. It will manage the life time of the lambda correctly.

std::function<void()> func;

{
    // The lambda is moved to func
    func = []{};
}

// func still holds it's instance of the lambda.

Also, std::function is smart. It may even hold the lambda using SBO, avoiding the allocation when possible, resulting in an increase of speed.

trueOrFalse isn't member of lambda, even though it captured it, doesn't make sense

That's because the members of the lambda are private. And it's okay, lambdas are meant to only expose it's call operator. If you want to mutate a member from the outside, you could emulate it using pointers or reference.

Also, since all lambda are instances of different type, and captures tend to use name of local variables, changing the name of a local variable could in fact breaking code else where, and that's not very desirable. Capture being private also ensure you keep control over captured data.

I suggest the lambda returning a lambda like above. It will let you setup values of captured data instead of having to mutate them later.

operator() overloading

Generic lambda does the basic cases:

auto overloaded = [](const auto& val) {
    std::cout << val << std::endl;
};

overloaded(4); // prints 4
overloaded(6.8); // prints 6.8
overloaded("test"); // prints test

If you have more complex cases, you can compose lambdas by inheriting from them:

// C++17 for simplicity
template<typename... Ls>
struct overload : Ls... {
    explicit overload(Ls... ls) noexcept : Ls{std::move(ls)}... {}

    using Ls::operator()...;
};

Now you can overload lambdas:

auto o = overload(
    []{},
    [i = 0](int) {},
    [&](double) {}
);

Here you can even have a different set of capture for each overload.

You can achieve the same syntax in C++14, but the implementation of overload is slightly different, and a bit more complex.

---

What you cannot do with a lambda but you can with functors is using them in a constexpr context:

constexpr void foo() {
    []{}(); // Ill formed
}

struct MyFunctor {
    constexpr MyFunctor() = default;

    constexpr void operator()(){}
};

constexpr void bar() {
    MyFunctor{}(); // okay
}

Note that this restriction is removed since C++17. Lambdas are allowed to be constexpr.

Another thing you cannot do with lambda today is type matching like in template.

auto lambda = [](auto someVec) {
    using T = typename decltype(someVec)::value_type; // ugh...
};

While in C++2a, you can do that instead:

auto lambda = []<typename T>(std::vector<T> someVec) {
    // Yay! Only vectors and got T!
};