C + + 11 lambda 实现和内存模型

My current understanding is that a lambda with no captured closure is exactly like a C callback. However, when the environment is captured either by value or by reference, an anonymous object is created on the stack.

No; it is always a C++ object with an unknown type, created on the stack. A capture-less lambda can be converted into a function pointer (though whether it is suitable for C calling conventions is implementation dependent), but that doesn't mean it is a function pointer.

When a value-closure must be returned from a function, one wraps it in std::function. What happens to the closure memory in this case?

A lambda isn't anything special in C++11. It's an object like any other object. A lambda expression results in a temporary, which can be used to initialize a variable on the stack:

auto lamb = []() {return 5;};

lamb is a stack object. It has a constructor and destructor. And it will follow all of the C++ rules for that. The type of lamb will contain the values/references that are captured; they will be members of that object, just like any other object members of any other type.

You can give it to a std::function:

auto func_lamb = std::function<int()>(lamb);

In this case, it will get a copy of the value of lamb. If lamb had captured anything by value, there would be two copies of those values; one in lamb, and one in func_lamb.

When the current scope ends, func_lamb will be destroyed, followed by lamb, as per the rules of cleaning up stack variables.

You could just as easily allocate one on the heap:

auto func_lamb_ptr = new std::function<int()>(lamb);

Exactly where the memory for the contents of a std::function goes is implementation-dependent, but the type-erasure employed by std::function generally requires at least one memory allocation. This is why std::function's constructor can take an allocator.

Is it freed whenever the std::function is freed, i.e., is it reference-counted like a std::shared_ptr?

std::function stores a copy of its contents. Like virtually every standard library C++ type, function uses value semantics. Thus, it is copyable; when it is copied, the new function object is completely separate. It is also moveable, so any internal allocations can be transferred appropriately without needing more allocating and copying.

Thus there is no need for reference counting.

Everything else you state is correct, assuming that "memory allocation" equates to "bad to use in real-time code".

C++ lambda is just a syntactic sugar around (anonymous) Functor class with overloaded operator() and std::function is just a wrapper around callables (i.e functors, lambdas, c-functions, ...) which does copy by value the "solid lambda object" from the current stack scope - to the heap.

To test the number of actual constructors/relocatons I made a test (using another level of wrapping to shared_ptr but its not the case). See for yourself:

#include <memory>
#include <string>
#include <iostream>


class Functor {
std::string greeting;
public:


Functor(const Functor &rhs) {
this->greeting = rhs.greeting;
std::cout << "Copy-Ctor \n";
}
Functor(std::string _greeting="Hello!"): greeting { _greeting } {
std::cout << "Ctor \n";
}


Functor & operator=(const Functor & rhs) {
greeting = rhs.greeting;
std::cout << "Copy-assigned\n";
return *this;
}


virtual ~Functor() {
std::cout << "Dtor\n";
}


void operator()()
{
std::cout << "hey" << "\n";
}
};


auto getFpp() {
std::shared_ptr<std::function<void()>> fp = std::make_shared<std::function<void()>>(Functor{}
);
(*fp)();
return fp;
}


int main() {
auto f = getFpp();
(*f)();
}

it makes this output:

Ctor
Copy-Ctor
Copy-Ctor
Dtor
Dtor
hey
hey
Dtor

Exactly same set of ctors/dtors would be called for the stack-allocated lambda object! (Now it calls Ctor for stack allocation, Copy-ctor (+ heap alloc) to construct it in std::function and another one for making shared_ptr heap allocation + construction of function)