I'm trying to std::bind a std::move on a std::unique_ptr. The resulting function object seems to be immutable, so it would be impossible to perform the move when the functor is invoked.
I suspect this is because of the same reason why lambdas are immutable by default - invoking them should do the same thing every time. However there are cases where they need to be mutable, which is why we have the mutable keyword.
void foo(std::unique_ptr<int>&& ptr)
{
cout << *ptr << endl;
}
int main()
{
std::unique_ptr<int> ptr = std::make_unique<int>(123);
std::bind(foo, std::move(ptr))(); // Doesn't compile
[&ptr]() { foo(std::move(ptr)); }(); // Equivalent, doesn't compile
[&ptr]() mutable { foo(std::move(ptr)); }(); // Compiles
return 0;
}
Instad of using bind I could wrap a function call in a mutable lambda. However at least to me personally bind looks much cleaner and simpler in this case.
I understand that invoking the mutable lambda twice would lead to undefined behavior, because I would be moving again from an already moved-from pointer. But in my case I know the functor will only be called once.
Is there a way I could use std::bind to do this? Is there a bind_mutable of sorts? If not, how should I go about writing it myself?
However at least to me personally bind looks much cleaner and simpler in this case.
Do not use std::bind in C++11. Use lambdas instead. std::bind has several issues excellently explained in this talk by Stephan T. Lavavej “functional: What's New, And Proper Usage".
It might look simpler and cleaner in this case, but it's not recommended.
Writing...
[&ptr]{ foo(std::move(ptr)); }();
...is the proper way of solving this problem.
Related
I'm seeing code that looks like this:
template<class Function>
void MyFunc(Function&& function) { function(...); }
What's the advantage of && here, as opposed to just copying the function by value? For reference, I'm using C++14.
The problem comes from avoiding copies.
Imagine this:
auto lambda = [ptr = std::make_unique<int>(0)]() mutable {
std::cout << *ptr;
ptr = std::make_unique<int>(*ptr + 1); // why not?
};
MyFunc(lambda); // use it normally
MyFunc([]{ std::cout << " end"; }); // use by using a temporary lambda
lambda() // just call the function after that
If the signature is MyFunc(Function f), it would require a std::move and the lambda would not be useable after the call.
If the signature is MyFunc(Function const& f), it would not work since the lambda is mutable.
If it was MyFunc(Function& f) then the temporary would not work.
You're basically left with MyFunc(Function&& f).
The real question however is "Do I need to support all these cases?"
I would tell: most of the time no. Most of the time, receiving the lambda by value is the simplest and support almost every cases. This is the way the STL went.
Why? Because perfect forwarding of function objects is really hard to get perfect, and you cannot call the function multiple times in most of the cases in a pefectly generic way. I would perfect forward a function only if I want to wrap it, want to completely avoid copies and I expect function objects that are ref qualified to temporaries.
The Problem
When creating schedulers the last copy or move of a function object is the last place that the function object is ever referenced (by a worker thread). If you were to use a std::function to store functions in the scheduler then any std::promises or std::packaged_task or other similarly move only types don't work as they cannot be copied by std::function.
Similarly, if you were to use std::packaged_task in the scheduler it imposes unnecessary overhead as many tasks do not require the std::future returned by packaged task at all.
The common and not great solution is to use a std::shared_ptr<std::promise> or a std::shared_ptr<std::packaged_task> which works but it imposes quite a lot of overhead.
The solution
A make_owner, similar to make_unique with one key difference, a move OR copy simply transfers control of destruction of the object. It is basically identical to std::unique_ptr, except that it is copyable (it basically always moves, even on a copy). Grosss....
This means that moving of std::functions doesn't require copies of the std::shared_ptr which require reference counting and it also means there is significantly less overhead on the reference counting etc. A single atomic pointer to the object would be needed and a move OR copy would transfer control. The major difference being that copy also transfers control, this might be a bit of a no-no in terms of strict language rules but I don't see another way around it.
This solution is bad because:
It ignores copy symantics.
It casts away const (in copy constructor and operator =)
Grrr
It isn't as nice of a solution as I'd like so if anybody knows another way to avoid using a shared pointer or only using packaged_tasks in a scheduler I'd love to hear it because I'm stumped...
I am pretty unsatisfied with this solution.... Any ideas?
I am able to re-implement std::function with move symantics but this seems like a massive pain in the arse and it has its own problems regarding object lifetime (but they already exist when using std::function with reference capture).
Some examples of the problem:
EDIT
Note in the target application I cannot do std::thread a (std::move(a)) as the scheduler threads are always running, at most they are put in a sleep state, never joined, never stopped. A fixed number of threads are in the thread pool, I cannot create threads for each task.
auto proms = std::make_unique<std::promise<int>>();
auto future = proms->get_future();
std::thread runner(std::move(std::function( [prom = std::move(proms)]() mutable noexcept
{
prom->set_value(80085);
})));
std::cout << future.get() << std::endl;
std::cin.get();
And an example with a packaged_task
auto pack = std::packaged_task<int(void)>
( []
{
return 1;
});
auto future = pack.get_future();
std::thread runner(std::move(std::function( [pack = std::move(pack)]() mutable noexcept
{
pack();
})));
std::cout << future.get() << std::endl;
std::cin.get();
EDIT
I need to do this from the context of a scheduler, I won't be able to move to the thread.
Please note that the above is minimum re-producible, std::async is not adequate for my application.
The main question is: Why you want to wrap a lambda with std::function before passing it to the std::thread constructor?
It is perfectly fine to do this:
std::thread runner([prom = std::move(proms)]() mutable noexcept
{
prom->set_value(80085);
});
You can find the explanation of why std::function does not allow you to store a move-only lambda here.
If you were going to pass std::function with wrapped lambda to some function, instead of:
void foo(std::function<void()> f)
{
std::thread runner(std::move(f));
/* ... */
}
foo(std::function<void()>([](){}));
You can do this:
void foo(std::thread runner)
{
/* ... */
}
foo(std::thread([](){}));
Update: It can be done in an old-fashioned way.
std::thread runner([prom_deleter = proms.get_deleter(), prom = proms.release()]() mutable noexcept
{
prom->set_value(80085);
// if `proms` deleter is of a `default_deleter` type
// the next line can be simplified to `delete prom;`
prom_deleter(prom);
});
I'm trying to make a function that accepts a shared pointer to some functor. With manually crafted functors there're no problems, but with lambda there are. I know that I can't use decltype with lambda - every new lambda declaration creates a new type. Right now I'm writing:
auto lambda = [](int a, float b)->int
{
return 42;
};
using LambdaType = decltype(lambda);
shared_ptr<LambdaType> ptr{ new LambdaType{ lambda } };
It works, but looks ugly. Moreover there's a copy constructor call! Is there any way to simplify?
You could use std::function as type.
Lambdas are merely auto written invokable objects to make simple code simple. It you want something beyond their default automatic storage behavior, write the type they write yourself.
It is illegal to have a lambda type in an unevaluated context. In an evaluated context, it creates a lambda in automatic storage. You want it on the free store. This requires at least logically a copy.
A horrible hack involving violating the unevaluated context rule, sizeof/alignof, aligned_storage_t, placement new, possibly unbounded compile time recursion (or maybe one with a static_assert), returning pointers to local variables, and the aliasing constructor of shared ptr, and requiring callers to write insane code might avoid calling the copy/move. But it is a bad idea, and simply using invokable objects is easier.
Of course, accepting the copy/move makes it trivial. But at that point, just use std::function unless you need something like varargs.
You state you do not want to force users to use std::function; but std::function would implicitly convert a compatible lambda into itself.
If you are willing to accept a copy, we can do this:
template<class T>
std::shared_ptr<std::decay_t<T>>
auto_shared( T&& t ) {
return std::make_shared<std::decay_t<T>>(std::forward<T>(t));
}
then auto ptr = auto_shared( [x=0]()mutable{ return x++; } ); is a non-type-erased shared pointer to a counting lambda. The lambda is copied (well, moved) into the shared storage.
If you want to avoid that copy, the client can write a manual function object and call make_shared<X>(ctor_args) on it.
There is no reasonable way to separate a lambdas type from its construction in C++ at this point.
if you catch something in lambda, it becomes algorithmically same as std::function, so use it freely. Also, std::function implements captured values memory management, so using std::shared_ptr on top of it is not required.
If you catch nothing, lambda is convertible to simple function pointer:
int(*ptr)(int,int) = [](int a, int b) -> int {
return a+b;
};
Functions are allocated statically and definitely shouldn't be deleted. So, you don't actually need std::shared_ptr
I have a function which returns a vector or set:
set<int> foo() {
set<int> bar;
// create and massage bar
return bar;
}
set<int> afoo = foo();
In this case, I create a temporary memory space in function foo(), and then
assign it to afoo by copying. I really want to avoid this copy, any easy way I
can do this in C++11? I think this has to do with the rvalue thing.
OK, update to the question: If I am going to return an object defined by myself,
not the vector or set thing, does that mean I should define a move constructor?
like this:
class value_to_return {
value_to_return (value_to_return && other) {
// how to write it here? I think std::move is supposed to be used?
}
}
THanks!!!
Modem C++ compiler will implement: given a type T:
If T has an accessible copy or move constructor, the compiler may
choose to elide the copy. This is the so-called (named) return value
optimization (RVO), which was specified even before C++11 and is
supported by most compilers.
Otherwise, if T has a move constructor, T is moved(Since C++11).
Otherwise, if T has a copy constructor, T is copied.
Otherwise, a compile-time error is emitted.
Check out return value optimization. A modern compiler will optimize this situation, and in straightforward situations like these, no copy will be made on any of the major compilers.
In principle, you could also create your object outside the function, and then call the function and pass the object to it by reference. That would be the old way of avoiding a copy, but it is unnecessary and undesirable now.
I usually work around this by having function signature as
void foo(set<int> *x)
Just pass it by reference or the other option is already mentioned in the comment.
Edit: I have changed the argument type to illustrate that x could be changed.
set<int> s;
foo(&s);
This is only preferred when you have an old compiler. I suppose that could be the case with some of the projects.
And, better thing to do will be Either to use move semantics with c++11. Or go ahead returning the container and look into RVO in modern compilers.
I've recently started using Boost.Asio in a project and would like to know whether anyone knows a clean solution to transfer ownership of a newly created socket to tcp::acceptor::async_accept, which would in turn transfer this ownership to the accept handler function.
This isn't an incoherent desire, mind you, since the handler is to be called exactly once.
I have noticed I can't std::bind() an std::unique_ptr<> as parameter, since std::bind() requires its parameters to be CopyConstructible, and rightfully so. Not only that, but Boost's AcceptHandler concept is also required to be CopyConstructible.
So my options would be:
Go the deprecated std::auto_ptr<> way of moving objects with the copy constructor, potentially causing obscure bugs on new releases of Boost.Asio.
Use std::shared_ptr<> and have no way to take the shared ownership off the pointer once it's not needed anymore, i.e. when it reaches the actual handler function (this is how the job is done on the examples at http://www.boost.org/doc/libs/1_43_0/doc/html/boost_asio/examples.html as far as I've read).
or
You have a better idea for me.
I'm pretty much at a loss here. Can anyone enlighten me?
I tried to find a way to do this using the c++0x standard library, but could not.
Eventually I settled on writing my own rvalue_reference_wrapper and rvalue_ref() convenience class. As per usual with std::bind, you need to wrap your non copyable object in something that is copyable (reference_wrapper is the best example). You could also have just passed a pointer, but that means changing your interface.
This worked on my machine:
#include <iostream>
#include <functional>
#include <memory>
template< class T >
struct rvalue_reference_wrapper
{
rvalue_reference_wrapper( T&& t )
: t_(std::move(t))
{}
operator T&&() const volatile
{
return std::move(t_);
}
private:
T&& t_;
};
template< class T >
rvalue_reference_wrapper<T> rvalue_ref( T&& t )
{
return rvalue_reference_wrapper<T>(std::move(t));
}
void go( std::unique_ptr<int> i )
{
std::cout << *i << std::endl;
}
int main()
{
std::unique_ptr<int> i(new int(1));
auto b = std::bind( go, rvalue_ref(std::move(i)) );
//auto b = std::bind( go, std::ref(std::move(i)) ); // Wont work
b();
}
I have not made the code bulletproof, but welcome some discussion about the need for an rvalue_reference_wrapper, or how to simulate one using std::reference_wrapper.
Also, for your specific case, you will likely need to write a difference version of rvalue_reference_wrapper, which holds the object by value not by rvalue reference, since your original unique_ptr is likely going to leave scope (and be destroyed) since you are using async asio calls.