ref to shared_ptr?

[.rhavin grobert]

are there any pro's and con's in using references to shared_ptr<>'s ?

example:

__________________________________________________
void obj::foo(shared_ptr<>); vs. void obj::foo(shared_ptr<>&);

and

shared_ptr<>& obj::foo2(); vs. shared_ptr<> obj::foo2();
__________________________________________________

....?


TIA, ~.rhavin

 

[Maxim Yegorushkin]

are there any pro's and con's in using references to shared_ptr<>'s ?

example:

__________________________________________________
void obj::foo(shared_ptr<>);   vs.  void obj::foo(shared_ptr<>&);

Passing shared_ptr by value causes a call to shared_ptr's copy
constructor just before the function call and a call to the destructor
upon leaving the function. On the other hand, passing by reference
does not involve any constructor/destructor calls (unless it is a
reference to const bound to a temporary object). It depends on an
application whether the difference is noticeable.

Speaking generally, functions that do not acquire or share the
ownership of passed objects should not be taking any smart pointers,
rather they should accept objects by plain reference/pointer.

and

shared_ptr<>& obj::foo2();    vs.    shared_ptr<> obj::foo2();

Performance considerations are the same as for passing shared_ptr to
functions.

Again, one should really think about interfaces and ownership. Is it
expected that the callers of obj::foo2() are going to share the
ownership of the object. If not, it is better to return a plain
pointer/reference.

 

[Marcel Müller]

Hi,

__________________________________________________
void obj::foo(shared_ptr<>); vs. void obj::foo(shared_ptr<>&);

and

shared_ptr<>& obj::foo2(); vs. shared_ptr<> obj::foo2();
__________________________________________________

well, in this case it is up to you to ensure the livetime of the
referenced object.

In general returning a reference to a shared_ptr is a bad advice, since
shared_ptr is explicitly designed to manage object lifetime in
situations like this. And the copy constructor of shared_ptr is quite
cheap, since it is always only a reference to your object.

Remember that when returning a reference to a shared_ptr, the pointer
may no longer point to the same object when you dereference it.
Or, if the shared_ptr instance is ownd by exactly one thread, it will
point to the same object, but the object's lifetime will neccessarily
exceed the lifetime of the shared_ptr in this case. So you could in fact
also return an ordinary pointer (or even better a reference) to your
object. This will more clearly show what is going on.

I think there is only one situation where it is siutable to return a
reference to a shared_ptr: if it is intended that the caller modifies
the shared_ptr (not only the object where it points to).


Marcel