You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One solution is to follow rule CP.4 of CppCoreGuidelines: "Think in terms of tasks, rather than threads". Thus, vroom should prefer std::async to std::jthread.
The text was updated successfully, but these errors were encountered:
The use of std::jthread over std::thread was introduced in 02eb40b as part of a refactoring based on the sonarcloud static analysis recommendations. A quick fix for anyone needing to build using Apple clang would be to simply git revert 02eb40b4e (works out of the box on the release branch).
Thanks for pointing out the recommendation in the core guidelines. I have virtually no knowledge of std::async but I can see the benefit of using a higher-level abstraction. So happy to look at options for this kind of replacement. The only potential concern would be to know whether we can still tune the number of underlying threads that are used. Not only do we do it currently, but we allow users to decide on that parameter with the -t option.
Apple clang MacOS does not accept yet
jthread
C++ 20 extension (see https://en.cppreference.com/w/cpp/compiler_support/20), while vroom uses it. Thus vroom does not compile with Apple clang.One solution is to follow rule CP.4 of CppCoreGuidelines: "Think in terms of tasks, rather than threads". Thus, vroom should prefer
std::async
tostd::jthread
.The text was updated successfully, but these errors were encountered: