How to pass a shared_ptr to a mutable object as a parameter?

Question

I want to pass an object by smart-pointer reference to a function. The function may change the value of the referenced object, but may not change the reference itself. There are two obvious ways to handle this.

The first approach to pass the shared_ptr by value - it is the reference, so doesn't itself need to be passed by reference. The apparent issue with this is copying of the reference, which suggests some reference-counting overhead.

void foo (shared_ptr<bar> p)

The second approach is to pass the shared_ptr by const reference - avoiding the copying of the shared_ptr instance, but instead implying that accesses to the referenced object need two layers of dereferencing instead of one.

void foo (const shared_ptr<bar> &p)

In practice, these theoretical overheads will normally be trivial and irrelevant. Which suggests to me that instead of choosing one approach or the other for each individual case, I should almost always follow some standard convention. Which leads to the question...

Is there a standard convention for which of these approaches I should normally choose? If so, which is the conventional choice?

EDIT - Probably worth mentioning - one reason to consider the pass-by-const-reference case is because there's a pre-existing convention that most class/struct instances are passed by const-reference rather than by value, and shared_ptr is a class. Of course it isn't a heavyweight class (the cost of copying is small), so the reasons behind that older convention may not apply.

Answer 1

Always pass shared_ptrs by value. If you pass a reference, you might run into the problem that a call to a function of the object managed by the shared_ptr might just reset it, and now you've got a dangling pointer. If you pass by value, you ensure that the object will survive the current function call.

See here for much, much more information.

---

Example:

#include <memory>
#include <iostream>

std::shared_ptr<int> ptr(new int(42));

void foo(){
  ptr.reset();
}

void bar(std::shared_ptr<int> const& p){
  foo();
  std::cout << *p;
}

int main(){
  bar(ptr);
}

---

This should be taken with a pinch of salt. It can be adapted to prove that no type should ever be passed by const-reference - see for example http://ideone.com/1IYyC, which Benjamin Lindley pointed out in the comments.

However, more complex variations of this kind of issue do arise by accident in practice. This is the reason, for example, why we are warned that iterators (as well as const-reference return values) are invalidated by methods that mutate the referenced container. These rules are easy enough to follow in general, but occasionally more indirect and unexpected examples can catch people by surprise.

That being the case, it's best to avoid the extra layer of referencing when it's not needed.

Answer 2

If the function manipulating the object it should not be relevant if the object is contained in a smart pointer. It should accept a T&. Free functions that manipulate values are considered bad style by some. Taking the object by reference to const and returning a new value can be cleaner.

Answer 3

I've been passing by const& based on the idea that somewhere up the call stack someone should be holding a copy of the shared_ptr and therefore its life is guaranteed for my entire execution.

In the case that you are executing on a different thread, you need a copy - and for that matter anyone that stores the shared_ptr (not just uses it for the duration of their method) needs to store a copy, not a reference.

And, now that I've written that I'll go and read why people seem to be supporting the opposite mentality.

Answer 4

An example to what @Xeo said:

void foo(shared_ptr<bar> &p)
{
    p.reset(); // ref_count == 0; memory is freed.
}

shared_ptr<bar> p(new bar); // ref_count == 1
foo(p);

This does not happen for const shared_ptr<bar> &p.