Open ltimaginea opened 2 years ago
This was mentioned in Issue #1781 for shared_ptr
Editors call: F.18 covers that for "sink" functions (for smart pointers, ownership transfer) to pass by &&
. In our desire to keep the smart pointer passing rules simple and avoid teaching &&
, we covered only unique_ptr
"sink" functions where pass by value happens to have the same effect because unique_ptr
happens to be move-only, but we did not cover other smart pointer "sink" functions. Those should pass by &&
. We might add a guideline saying so, or perhaps add a note saying so.
Should add the discussion about
shared_ptr<widget>&&
andunique_ptr<widget>&&
in Smart pointer rule summary .Link: Smart pointer rule summary
For R.34's example code, when enter the function, the shared_ptr is copy-constructed, and this requires incrementing the strong reference count. This can incur performance costs. But if the parameter type is
shared_ptr<widget>&&
, this directly addresses the cost. The rvalue reference typeshared_ptr<widget>&&
is more efficient than the value typeshared_ptr<widget>
. So, I don't understand R.34 Enforcement's final line:I modified the example code for R.34 , I think the example code should be written like this:
On the other hand, R.32 and R.33 talk about
unique_ptr<widget>
andunique_ptr<widget>&
. But I think,unique_ptr<widget>&&
is also very useful. If we take aunique_ptr<widget>
parameter, its total cost would be two moves. But if we take aunique_ptr<widget>&&
parameter, the total cost is one move.The screenshots from the Scott Meyers's Effective Modern C++ Item41 is as follows:
So, I think we should add the discussion about
shared_ptr<widget>&&
andunique_ptr<widget>&&
in Smart pointer rule summary .