When should I use raw pointers over smart pointers?

Question

After reading this answer, it looks like it is a best practice to use smart pointers as much as possible, and to reduce the usage of "normal"/raw pointers to minimum.

Is that true?

Answer 1

No, it's not true. If a function needs a pointer and has nothing to do with ownership, then I strongly believe that a regular pointer should be passed for the following reasons:

• No ownership, therefore you don't know what kind of a smart pointer to pass
• If you pass a specific pointer, like shared_ptr, then you won't be able to pass, say, scoped_ptr

The rule would be this - if you know that an entity must take a certain kind of ownership of the object, always use smart pointers - the one that gives you the kind of ownership you need. If there is no notion of ownership, never use smart pointers.

Example1:

void PrintObject(shared_ptr<const Object> po) //bad {     if(po)       po->Print();     else       log_error(); }  void PrintObject(const Object* po) //good {     if(po)       po->Print();     else       log_error(); } 

Example2:

Object* createObject() //bad {     return new Object; }  some_smart_ptr<Object> createObject() //good {    return some_smart_ptr<Object>(new Object); } 

Answer 2

Using smart pointers to manage ownership is the right thing to do. Conversely, using raw pointers wherever ownership is not an issue is not wrong.

Here are some perfectly legitimate use of raw pointers (remember, it is always assumed they are non-owning):

where they compete with references

• argument passing; but references can't be null, so are preferable
• as class members to denote association rather than composition; usually preferable to references because the semantics of assignment are more straightforward and in addition an invariant set up by the constructors can ensure that they are not 0 for the lifetime of the object
• as a handle to a (possibly polymorphic) object owned somewhere else; references can't be null so again they are preferable
• std::bind uses a convention where arguments that are passed are copied into the resulting functor; however std::bind(&T::some_member, this, ...) only makes a copy of the pointer whereas std::bind(&T::some_member, *this, ...) copies the object; std::bind(&T::some_member, std::ref(*this), ...) is an alternative

where they do not compete with references

• as iterators!
• argument passing of optional parameters; here they compete with boost::optional<T&>
• as a handle to a (possibly polymorphic) object owned somewhere else, when they can't be declared at the site of initialization; again, competing with boost::optional<T&>

As a reminder, it's almost always wrong to write a function (that is not a constructor, or a function member that e.g. takes ownership) that accepts a smart pointer unless it in turn pass it to a constructor (e.g. it's correct for std::async because semantically it's close to being a call to the std::thread constructor). If it's synchronous, no need for the smart pointer.

---

To recap, here's a snippet that demonstrates several of the above uses. We're writing and using a class that applies a functor to every element of an std::vector<int> while writing some output.

class apply_and_log { public:     // C++03 exception: it's acceptable to pass by pointer to const     // to avoid apply_and_log(std::cout, std::vector<int>())     // notice that our pointer would be left dangling after call to constructor     // this still adds a requirement on the caller that v != 0 or that we throw on 0     apply_and_log(std::ostream& os, std::vector<int> const* v)         : log(&os)         , data(v)     {}      // C++0x alternative     // also usable for C++03 with requirement on v     apply_and_log(std::ostream& os, std::vector<int> const& v)         : log(&os)         , data(&v)     {}     // now apply_and_log(std::cout, std::vector<int> {}) is invalid in C++0x     // && is also acceptable instead of const&&     apply_and_log(std::ostream& os, std::vector<int> const&&) = delete;      // Notice that without effort copy (also move), assignment and destruction     // are correct.     // Class invariants: member pointers are never 0.     // Requirements on construction: the passed stream and vector must outlive *this      typedef std::function<void(std::vector<int> const&)> callback_type;      // optional callback     // alternative: boost::optional<callback_type&>     void     do_work(callback_type* callback)     {         // for convenience         auto& v = *data;          // using raw pointers as iterators         int* begin = &v[0];         int* end = begin + v.size();         // ...          if(callback) {             callback(v);         }     }  private:     // association: we use a pointer     // notice that the type is polymorphic and non-copyable,     // so composition is not a reasonable option     std::ostream* log;      // association: we use a pointer to const     // contrived example for the constructors     std::vector<int> const* data; };