Timeline for C++11 lambda implementation and memory model
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 12, 2020 at 13:33 | comment | added | jrh | If lambda expressions have the same scoping rules as regular variables (and they're allocated on the stack) does that mean that attaching lambdas to signals in Qt is okay because the lambda is uh.. passed by value into connect and copied? | |
| Sep 30, 2016 at 5:16 | comment | added | AnT stands with Russia | Claiming that lambdas are "created on the stack" is too aggressive. Firstly, lambda objects are temporaries, meaning that it is unspecified where they are created. Secondly, lambda expressions are allowed in non-local scopes, which means that stack is not necessarily a viable memory source for them. | |
| Aug 22, 2016 at 15:57 | comment | added | Nicol Bolas | @Yakk: How do you define "large"? Is an object with two pointers' of state "large"? How about 3 or 4? Also, object size is not the only issue; if the object isn't nothrow-moveable, it must be stored in an allocation, since function has a noexcept move constructor. The whole point of saying "generally requires" is that I'm not saying "always requires": that there are circumstances where no allocation will be performed. | |
| Aug 22, 2016 at 15:09 | comment | added | Yakk - Adam Nevraumont | @NicolBolas Ok; but "generally requires at least one memory allocation" isn't true, or is at least misleading. It can do a memory allocation, but it is only generally required for large objects (are you aware of an implementation that allocates when passed an object with a pointer or less worth of state?) To be concrete, I would not expect any heap allocations for any of the lambdas the OP included in the question if stored in a std::function on any compiler I work on; I could be wrong. | |
| Aug 22, 2016 at 15:00 | comment | added | Nicol Bolas | @Yakk:: The standard only requires that it not allocate memory if the given callable is "passed via reference_wrapper or a function pointer." So even with a member pointer, you are not guaranteed not to allocate memory. | |
| Aug 22, 2016 at 14:56 | comment | added | Yakk - Adam Nevraumont | Correction to "generally requires at least one memory allocation" may be in order. I was under the impression that small enough std::function where mandated to not throw, and hence cannot do a memory allocation. I do not know if that mandate was in force in C++11, but even in C++11 it is clearly possible to do type erasure without allocating memory, unless C++11 forced it somehow. | |
| Jul 3, 2016 at 13:10 | comment | added | bisthebis | I may be late, but you can return a lambda without wrapping it, juste use auto as return type. Something like "aute getLambda(){ return [](){cout << "Hello world !";};} | |
| Oct 16, 2015 at 12:59 | comment | added | 5gon12eder | I want to add that the standard more or less indirectly mandates (§ 20.8.11.2.1 [func.wrap.func.con] ¶ 5) that if a lambda does not capture anything, it can be stored in a std::function object without dynamic memory allocation going on. | |
| May 10, 2015 at 9:33 | comment | added | Llamageddon | Is the entire function's code copied, or is the original function compile-time-allocated and passed the closed-over values? | |
| Aug 31, 2012 at 9:20 | comment | added | Nicol Bolas | @Steve: Yes; you have to wrap a lambda in some kind of container in order for it to exit the scope. | |
| Aug 31, 2012 at 3:39 | vote | accept | Steve | ||
| Aug 31, 2012 at 3:38 | comment | added | Steve | Excellent explanation, thank you. So the creation of std::function is the point at which the memory is allocated and copied. It seems to follow that there is no way to return a closure (since they are allocated on the stack), without first copying into a std::function, yes? | |
| Aug 30, 2012 at 18:43 | history | answered | Nicol Bolas | CC BY-SA 3.0 |