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”.