ref to shared_ptr?

Discussion in 'C++' started by .rhavin grobert, Oct 22, 2008.

  1. 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;)
    .rhavin grobert, Oct 22, 2008
    #1
    1. Advertising

  2. On Oct 22, 4:04 pm, ".rhavin grobert" <> wrote:
    > 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.

    --
    Max
    Maxim Yegorushkin, Oct 22, 2008
    #2
    1. Advertising

  3. Hi,

    ..rhavin grobert schrieb:
    > __________________________________________________
    > 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
    Marcel Müller, Oct 22, 2008
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Colin Caughie
    Replies:
    1
    Views:
    693
    Shooting
    Aug 29, 2006
  2. Replies:
    0
    Views:
    330
  3. Replies:
    22
    Views:
    737
    peter koch
    Apr 30, 2008
  4. Replies:
    6
    Views:
    332
    James Kanze
    Apr 29, 2008
  5. Navindra Umanee

    strong ref from weak ref?

    Navindra Umanee, Feb 12, 2005, in forum: Ruby
    Replies:
    2
    Views:
    135
    Navindra Umanee
    Feb 12, 2005
Loading...

Share This Page