Correctly using smart pointers

Question

I'm having trouble getting things organized properly with smart pointers. Almost to the point that I feel compelled to go back to using normal pointers.

I would like to make it easy to use smart pointers throughout the program without having to type shared_ptr<...> every time. One solution I think of right away is to make a template class and add a typedef sptr to it so I can do class Derived : public Object < Derived > .. and then use Derived::sptr = ... But this obviously is horrible because it does not work with another class that is then derived from Derived object.

And even doing typedef shared_ptr<..> MyObjectPtr is horrible because then it needs to be done for each kind of smart pointer for consistency's sake, or at least for unique_ptr and shared_ptr.

So what's the standard way people use smart pointers? Because frankly I'm starting to see it as being too much hassle to use them. :/

Answer 1

So what's the standard way people use smart pointers?

Rarely. The fact that you find it a hassle to use them is a sign that you over-use pointers. Try to refactor your code to make pointers the exception , not the rule. shared_ptr in particular has its niche, but it's a small one: namely, when you genuinely have to share ownership of a resource between several objects. This is a rare situation.

Because frankly I'm starting to see it as being too much hassle to use them. :/

Agreed. That's the main reason not to use pointers .

There are more ways to avoid pointers. In particular, shared_ptr really only needs to spelled out when you actually need to pass ownership . In functions which don't deal with ownership, you wouldn't pass a shared_ptr , or a raw pointer; you would pass a reference, and dereference the pointer upon calling the function.

And inside functions you almost never need to spell out the type; for instance, you can (and should) simply say auto x = …; instead of shared_ptr<Class> x = …; to initialise variables.

In summary , you should only need to spell out shared_ptr in very few places in your code.

Answer 2

I have a lot of code that creates objects dynamically. So using pointers is necessary because the number of objects is not known from the start. An object is created in one subsystem, then stored in another, then passed for further processing to the subsystem that created it. So that I guess means using shared_ptr. Good design? I don't know, but it seems most logical to ask subsystem to create a concrete object that it owns, return a pointer to an interface for that object and then pass it for further processing to another piece of code that will interact with the object through it's abstract interface.

I could return unique_ptr from factory method. But then I would run into trouble if I need to pass the object for processing multiple times. Because I would still need to know about the object after I pass it to another method and unique_ptr would mean that I lose track of the object after doing move(). Since I need to have at least two references to the object this means using shared_ptr.

I heard somewhere that most commonly used smart pointer is unique_ptr. Certainly not so in my application. I end up with using shared_ptr mush more often. Is this a sign of bad design then?