Using std::shared_ptr as a Last Resort in C++

cc++11smart-pointer

I was just watching the "Going Native 2012" streams and I noticed the discussion about std::shared_ptr. I was a bit surprised to hear Bjarne's somewhat negative view on std::shared_ptr and his comment that it should be used as a "last resort" when an object's life-time is uncertain (which I believe, according to him, should infrequently be the case).

Would anyone care to explain this in a bit more depth? How can we program without std::shared_ptr and still manage object life-times in a safe way?

Best Answer

If you can avoid shared ownership then your application will be simpler and easier to understand and hence less susceptible to bugs introduced during maintenance. Complex or unclear ownership models tend to lead to difficult to follow couplings of different parts of the application through shared state that may not be easily trackable.

Given this, it is preferable to use objects with automatic storage duration and to have "value" sub-objects. Failing this, unique_ptr may be a good alternative with shared_ptr being - if not a last resort - some way down the list of desirable tools.

Related Solutions

C++11 – Why std::stoi Exists but Not std::itos

I was mistaken, there is a set of "Xtos" functions, they are all just named to_string. Each to_string is overloaded to take a different basic type, i.e.:

std::string to_string(float f);
std::string to_string(int f);
...

See here for more info.

C++ – Documenting the Effect of std::move

The r-value reference only binds to rvalues. In the above code, Other(std::string &&) will not be considered. So only problem might be if the function std::string & but moved it internally.

The only way to get r-value out of l-value is a std::move. So as long as you take care not to use std::move on function argument you received by l-value reference, there will be no surprises.

Moving something you received by l-value reference should be considered a bug. Unfortunately the rules of the language itself are unable to catch it, so it's a job for a static checker. I don't know whether any of them does already though.

Of course a function taking a non-const l-value reference could always screw up the passed object and the move just adds another way to do it, but the problem already existed.

I would generally recommend avoiding functions taking non-const l-value references, because functions modifying their argument are never particularly readable. A method is expected to modify it's invocant (unless it's a getter), but modifying other arguments makes the data flow more complicated and less obvious. In C++11 move makes returning objects almost as efficient as modifying reference and std::tuple with std::tie allow returning multiple values, so most uses of argument modifying can be rewritten without significant loss of efficiency.

As for proper use of std::move note that most efficient way to write setters that were previously written taking const reference and copied from it should now take by value and move from it. The argument construction in caller will do move if possible and copy otherwise.

Best Answer

Related Solutions

C++11 – Why std::stoi Exists but Not std::itos

C++ – Documenting the Effect of std::move

Related Topic