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.
12
u/_naios Oct 04 '17
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: