C++ FAQ question [26.13] What should be returned from a function?

Discussion in 'C++' started by krel, Apr 5, 2010.

  1. krel

    krel Guest

    Two of the cases mentioned are:

    - shared_ptr to a member that was allocated via new — this has tradeoffs
    that are very similar to those of returning a member by pointer or by
    reference; see those bullets for the tradeoffs. The advantage is that
    callers can legitimately hold onto and use the returned pointer after
    the this-object dies.

    - local auto_ptr or shared_ptr to freestore-allocated copy of the datum.
    This is useful for polymorphic objects, since it lets you have the
    effect of return-by-value yet without the "slicing" problem. The
    performance needs to be evaluated on a case-by-case basis.

    Perhaps it's the wording, but I don't understand the difference between
    these two, supposedly different, options.
    krel, Apr 5, 2010
    #1
    1. Advertising

  2. krel

    Robert Fendt Guest

    Re: C++ FAQ question [26.13] What should be returned from afunction?

    And thus spake krel <>
    Mon, 05 Apr 2010 12:41:39 -0300:

    > - shared_ptr to a member that was allocated via new — this has tradeoffs
    > that are very similar to those of returning a member by pointer or by
    > reference; see those bullets for the tradeoffs. The advantage is that
    > callers can legitimately hold onto and use the returned pointer after
    > the this-object dies.


    struct Foo
    {
    foo() : str_(new std::string("Hello, World")) {}

    shared_ptr<std::string> get_str() {return str_;}

    shared_ptr<std::string> str_;
    };

    get_str() returns a shared_ptr to a string, and since inside the
    Foo class this member is also held via a shared_ptr (the FAQ
    should perhaps be a bit more clear on that point), it is legal
    to get a pointer, i.e.

    Foo f;
    shared_ptr<std::string> my_str = f.get_str();

    and hold on to it even after the Foo object is deleted. If it
    would be a reference or a naked pointer, then doing something
    like that would lead to big trouble.

    > - local auto_ptr or shared_ptr to freestore-allocated copy of the datum.
    > This is useful for polymorphic objects, since it lets you have the
    > effect of return-by-value yet without the "slicing" problem. The
    > performance needs to be evaluated on a case-by-case basis.


    class Bar;

    class Foo
    {
    public:
    virtual void do_something() {};

    Foo() {};
    virtual ~Foo() {};

    static Foo* get_instance() {return new Bar;}
    };

    class Bar: public Foo
    {
    public:
    void do_something() {x = 0;}

    private:
    int x;
    }

    In this scenario, one e.g. gets an instance via a factory without
    knowing exactly what implementation of the base class one gets
    (and without caring about it). If the factory would try to
    return the object by value, then this does not work, since

    Foo my_copy = Foo::get_instance();

    would slice the temporary Bar object down to a Foo object.
    However, if you return a pointer, you get polymorphism, and the
    following works just fine:

    std::auto_ptr<Foo> my_ptr(Foo::get_instance());

    By doing this, the returned value is destroyed when exiting the
    current scope, just like a returned value copy on the stack
    would, since you 'wrap' the heap object in a stack object
    taking care of memory management. On the other hand, you still
    get full polymorphism (i.e., you don't have to know that the Foo
    object returned is actually a Bar object).

    > Perhaps it's the wording, but I don't understand the difference between
    > these two, supposedly different, options.


    HTH.

    Regards,
    Robert
    Robert Fendt, Apr 5, 2010
    #2
    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. hansiman
    Replies:
    7
    Views:
    1,516
    Kevin Spencer
    May 11, 2005
  2. komal
    Replies:
    6
    Views:
    1,397
    msalters
    Jan 25, 2005
  3. Borse, Ganesh
    Replies:
    0
    Views:
    303
    Borse, Ganesh
    Nov 15, 2007
  4. ~~~ .NET Ed ~~~

    How should control images should be handled?

    ~~~ .NET Ed ~~~, Oct 31, 2004, in forum: ASP .Net Building Controls
    Replies:
    1
    Views:
    212
    John Saunders
    Nov 3, 2004
  5. Josef 'Jupp' SCHUGT

    What the FAQs should and should not contain

    Josef 'Jupp' SCHUGT, Aug 19, 2005, in forum: Ruby
    Replies:
    0
    Views:
    172
    Josef 'Jupp' SCHUGT
    Aug 19, 2005
Loading...

Share This Page