{"id":186,"date":"2023-09-27T22:33:28","date_gmt":"2023-09-27T20:33:28","guid":{"rendered":"https:\/\/www.arnorehn.de\/blog\/?p=186"},"modified":"2023-09-27T22:35:03","modified_gmt":"2023-09-27T20:35:03","slug":"pitfalls-of-lambda-capture-initialization","status":"publish","type":"post","link":"https:\/\/www.arnorehn.de\/blog\/2023\/09\/27\/pitfalls-of-lambda-capture-initialization\/","title":{"rendered":"Pitfalls of lambda capture initialization"},"content":{"rendered":"\n

Recently, I’ve stumbled across some behavior of C++ lambda captures that has, initially, made absolutely no sense to me. Apparently, I wasn’t alone with this, because it has resulted in a memory leak<\/a> in QtFuture::whenAll()<\/code> and QtFuture::whenAny()<\/code> (now fixed; more on that further down).<\/p>\n\n\n\n

I find the corner cases of C++ quite interesting, so I wanted to share this. Luckily, we can discuss this without getting knee-deep into the internals of QtFuture<\/code>. So, without further ado:<\/p>\n\n\n\n

Time for an example<\/h2>\n\n\n\n

Consider this (godbolt<\/a>):<\/p>\n\n\n\n

#include <iostream>\n#include <functional>\n#include <memory>\n#include <cassert>\n#include <vector>\n\nstruct Job\n{\n    template<class T>\n    Job(T &&func) : func(std::forward<T>(func)) {}\n\n    void run() { func(); hasRun = true; }\n\n    std::function<void()> func;\n    bool hasRun = false;\n};\n\nstd::vector<Job> jobs;\n\ntemplate<class T>\nvoid enqueueJob(T &&func)\n{\n    jobs.emplace_back([func=std::forward<T>(func)]() mutable {\n        std::cout << \"Starting job...\" << std::endl;\n        \/\/ Move func to ensure that it is destroyed after running\n        auto fn = std::move(func);\n        fn();\n        std::cout << \"Job finished.\" << std::endl;\n    });\n}\n\nint main()\n{\n    struct Data {};\n    std::weak_ptr<Data> observer;\n    {\n        auto context = std::make_shared<Data>();\n        observer = context;\n        enqueueJob([context] {\n            std::cout << \"Running...\" << std::endl;\n        });\n    }\n    for (auto &job : jobs) {\n        job.run();\n    }\n    assert((observer.use_count() == 0) \n                && \"There's still shared data left!\");\n}\n<\/pre>\n\n\n\n
Output:<\/p>\n\n\n\n
Starting job...\nRunning...\nJob finished.<\/pre>\n\n\n\n
The code is fairly straight forward. There’s a list of jobs to which we can be append with enqueueJob()<\/code>. enqueueJob()<\/code> wraps the passed callable with some debug output and ensures that it is destroyed after calling it. The Job<\/code> objects themselves are kept around a little longer; we can imagine doing something with them, even though the jobs have already been run.
In main()<\/code>, we enqueue a job that captures some shared state Data<\/code>, run all jobs, and finally assert that the shared Data<\/code> has been destroyed. So far, so good.<\/p>\n\n\n\n
Now you might have some issues with the code. Apart from the structure, which, arguably, is a little forced, you might think “context<\/code> is never modified, so it should be const<\/code>!”. And you’re right, that would be better. So let’s change it (godbolt<\/a>):<\/p>\n\n\n\n
--- old\n+++ new\n@@ -34,7 +34,7 @@\n     struct Data {};\n     std::weak_ptr<Data> observer;\n     {\n-        auto context = std::make_shared<Data>();\n+        const auto context = std::make_shared<Data>();\n         observer = context;\n         enqueueJob([context] {\n             std::cout << \"Running...\" << std::endl;\n<\/pre>\n\n\n\n
Looks like a trivial change, right? But when we run it, the assertion fails now!<\/p>\n\n\n\n
int main(): Assertion `(observer.use_count() == 0) && \"There's still shared data left!\"' failed.<\/pre>\n\n\n\n
How can this be? We’ve just declared a variable const<\/code> that isn’t even used once<\/em>! This does not seem to make any sense. 
But it gets better: we can fix this by adding what looks like a no-op (godbolt<\/a>):<\/p>\n\n\n\n
--- old\n+++ new\n@@ -34,9 +34,9 @@\n     struct Data {};\n     std::weak_ptr<Data> observer;\n     {\n-        auto context = std::make_shared<Data>();\n+        const auto context = std::make_shared<Data>();\n         observer = context;\n-        enqueueJob([context] {\n+        enqueueJob([context=context] {\n             std::cout << \"Running...\" << std::endl;\n         });\n     }<\/pre>\n\n\n\n
Wait, what? We just have to tell the compiler that we really<\/em> want to capture context<\/code> by the name context<\/code> – and then it will correctly destroy the shared data? Would this be an application for the really<\/code> keyword<\/a>? Whatever it is, it works; you can check it on godbolt<\/a> yourself.<\/p>\n\n\n\n
When I first stumbled across this behavior, I just couldn’t wrap my head around it. I was about to think “compiler bug”, as unlikely as that may be. But GCC and Clang both<\/em> behave like this, so it’s pretty much guaranteed not<\/strong> to be a compiler bug.<\/p>\n\n\n\n
So, after combing through the interwebs, I’ve found this StackOverflow answer<\/a> that gives the right hint: [context]<\/code> is not the same as [context=context]<\/code>! The latter drops cv<\/code> qualifiers while the former does not<\/strong>! Quoting cppreference.com<\/a>:<\/p>\n\n\n\n
\n
Those data members that correspond to captures without initializers are direct-initialized<\/a> when the lambda-expression is evaluated. Those that correspond to captures with initializers are initialized as the initializer requires (could be copy- or direct-initialization). If an array is captured, array elements are direct-initialized in increasing index order. The order in which the data members are initialized is the order in which they are declared (which is unspecified).<\/p>\nhttps:\/\/en.cppreference.com\/w\/cpp\/language\/lambda<\/a><\/cite><\/blockquote>\n\n\n\n
So [context]<\/code> will direct-initialize the corresponding data member, whereas [context=context]<\/code> (in this case) does copy-initialization! In terms of code this means:<\/p>\n\n\n\n