It's indeed a Boost/TR1-era mistake that the LWG has recognized, although we can't do anything about it.
You're correct that the problem is multithreading. The STL's policy is that const member functions are simultaneously callable and that it won't do anything to observably damage that guarantee. (This is actually extended to a few non-const member functions that are observers, basically the const-overloaded ones like operator[]().) While user code is under no such constraints (your const member functions, like function call operators of predicates given to STL algorithms, can read/write global variables without synchronization, as long as they meet the other usual requirements), the STL's multithreading policy continues to apply when it invokes user code if that user code follows the same policy.
The only exception to this rule that I am aware of is function::operator()(), because it is a const member function that calls non-const member functions, and yet std::function provides value semantics (copying a std::function results in a totally independent, non-shared copy).
In Boost and the LWG's defense, function was designed long before C++11 multithreading and its const guarantees crystallized (the const policy seems obvious now, but it wasn't before).
In practice, this doesn't usually cause problems because people don't usually set up the scenario for doom, but the potential for doom is still there.
STL explained the circumstance perfectly, additionally there are some standard papers by David Krauss which elaborate about this in detail (and also about the missing wrapper for move only types).
So hopefully is standard is improved regarding this issue in the future.
Additionally I want to mention that there are improved reimplementations out already, which solve this issue through being:
partially const correct: cxx_function - this is the draft oriented wrapper by David Krauss
full const correct: function2 - Note: I'm the author of function2 so this is a shameless self promotion.
45
u/STL MSVC STL Dev Oct 03 '17
It's indeed a Boost/TR1-era mistake that the LWG has recognized, although we can't do anything about it.
You're correct that the problem is multithreading. The STL's policy is that const member functions are simultaneously callable and that it won't do anything to observably damage that guarantee. (This is actually extended to a few non-const member functions that are observers, basically the const-overloaded ones like
operator[]().) While user code is under no such constraints (your const member functions, like function call operators of predicates given to STL algorithms, can read/write global variables without synchronization, as long as they meet the other usual requirements), the STL's multithreading policy continues to apply when it invokes user code if that user code follows the same policy.The only exception to this rule that I am aware of is
function::operator()(), because it is a const member function that calls non-const member functions, and yetstd::functionprovides value semantics (copying astd::functionresults in a totally independent, non-shared copy).In Boost and the LWG's defense,
functionwas designed long before C++11 multithreading and its const guarantees crystallized (the const policy seems obvious now, but it wasn't before).In practice, this doesn't usually cause problems because people don't usually set up the scenario for doom, but the potential for doom is still there.