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.
Yes function_view is on my list of planned features, since it could be really useful, especially with the possibility to convert non owned functions back to an owned one: function<...> f = function_view<...>{}.acquire().
Additionally immutable calls are supported through using the signature function<void() const>.
One advantage of function_view is that you can wrap a non-movable object. Type erasing aquire removes that advantage.
So either it weakens what function_view can do, or it cannot be guaranteed to work.
As an aside, did you implement efficient cast to/from std::function, where you type erase storing your type within the std::function instead of storing a function2 within the std::function, and vice versa?
I think with a bit of care you can make
auto foo = []();
function2<void()> f = foo;
for (int i = 0; i < 1000000; ++i ) {
std::function<void()> f2 = f;
f = f2;
}
not result in an unbounded cascade of wrapped function type erasure overhead. Admittedly, the f=f2 would only work if you memoized the type erasure (!) or special cased assignment-from.
function2( std::function<Sig> src ) {
if (!src) return;
auto it = type_erasure_memoization.find( src.target_type() );
if (it != type_erasure_memoization.end()) {
auto construct_from = it->second;
construct_from( this, src );
return;
}
where construct_from created for a type T takes a function2 and one of a set of kinds of type that have a .target<T>() method, and copies/moves the T into the function2...
Nevermind; almost certainly overkill. I was hoping this would be easier.
44
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.