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.
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 theshared_ptrmight 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:
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.