It’s pretty well known that the default behaviour of std::bind and std::thread is that it will copy (or move) the arguments passed to it, and to use reference semantics we will have to use reference wrappers.
-
Does anyone know why this makes a good default behaviour? Esp. in C++11 with rvalue reference and perfect forwarding, it seems to me that it makes more sense to just perfectly forward the arguments.
-
std::make_shared though doesn’t always copy/move but just perfectly forward the provided arguments. Why are there two seemingly different behaviour of forwarding arguments here? (std::thread and std::bind that always copy/move vs std::make_shared that don’t)
make_sharedforwards to a constructor that is being called now. If the constructor uses call by reference semantics, it will get the reference; if it does call by value, it will make a copy. No problem here either way.bindcreates a delayed call to a function that is called at some unknown points in the future, when the local context is potentially gone. Ifbindwere using perfect forwarding, you would have to copy the arguments that are normally sent byreference and not known to be live at the time of the actual call, store them somewhere, and manage that storage. With the current semanticsbinddoes it for you.