Pass shared_ptr by value vs pass by const T*

Question

I was told that the only benefit of passing shared_ptr by value is sharing ownership, so I am trying to come up with example where we must pass shared_ptr by value rather than otherwise.

class Foo {
  public:
    void p() const {}
};

void bar(std::shared_ptr<Foo> f) {f->p();}
void bar2(const Foo* f) {f->p();}

int main() {
  std::shared_ptr<Foo> f = std::make_shared<Foo>();
  bar(f); // OK
  bar2(f.get()); // OK
}

The only example I can came up with seems to be a multiple thread environment where if f is created in one thread and passed to another thread, in that case it seems that shared_ptr is needed, otherwise the object may expire in the other thread.

Could someone provide a simple example where bar would work but bar2 would run into an issue in a single thread program? I am wondering if bar and bar2 will always work in a single thread program.

This could help me understand how to design proper APIs.

---

EDIT: Based on the reply, seems that my understanding of ownership was wrong. If I am designing some utility-like API, similar to bar/bar2, then I don't need to worry about ownership. Ownership makes sense when there are objects involved.

Answer 1

Sharing ownership has some relation to multithreading, but not as much as you seem to expect.

Sharing ownership is about sorting out who is responsible for releasing some resource when it is no longer needed. Smart pointers help you with the "when is it no longer needed?" part and the "releasing" part is a destructor call.

Suppose you have a class that manages some device, for example a printer. You want to share the same printer instance between different other instances making use of it, and when they are all done, the printer object should get destroyed. Then you can use a std::shared_ptr:

 struct foo {
    std::shared_ptr<printer> prtr;
 };

This is just to point you in the right direction. Now make the member private and write a constructor to initialize it from a std::shared_ptr passed from outside. That would be a case where you can consider to pass the smart pointer by value.

Your bar does not participate in ownership. Neither bar nor bar2 care how the objects lifetime is managed. It simply does not matter. The object is alive when the functions are called and it is alive when the functions returns. The functions do not hold on to a reference or pointer to the objects (they could store it in a function local static, but they don't).

When a function is not participating in ownership it should not take a std::shared_ptr, but either a reference or pointer, depending on whether nullptr is valid input. nullptr is no valid input for your functions, hence they should use a reference:

void bar(const Foo& f) {f.p();}

PS: I suggest you to consult the cpp core guidelines. I don't remember for sure, but I'd expect some guides for how to pass shared pointers.