C++ best practice: Returning reference vs. object

Question

I'm trying to learn C++, and trying to understand returning objects. I seem to see 2 ways of doing this, and need to understand what is the best practice.

Option 1:

QList<Weight *> ret;
Weight *weight = new Weight(cname, "Weight");
ret.append(weight);
ret.append(c);
return &ret;

Option 2:

QList<Weight *> *ret = new QList();
Weight *weight = new Weight(cname, "Weight");
ret->append(weight);
ret->append(c);
return ret;

(of course, I may not understand this yet either).

Which way is considered best-practice, and should be followed?

Answer 1

Option 1 is defective. When you declare an object

QList<Weight *> ret; 

it only lives in the local scope. It is destroyed when the function exits. However, you can make this work with

return ret; // no "&" 

Now, although ret is destroyed, a copy is made first and passed back to the caller.

This is the generally preferred methodology. In fact, the copy-and-destroy operation (which accomplishes nothing, really) is usually elided, or optimized out and you get a fast, elegant program.

Option 2 works, but then you have a pointer to the heap. One way of looking at C++ is that the purpose of the language is to avoid manual memory management such as that. Sometimes you do want to manage objects on the heap, but option 1 still allows that:

QList<Weight *> *myList = new QList<Weight *>( getWeights() ); 

where getWeights is your example function. (In this case, you may have to define a copy constructor QList::QList( QList const & ), but like the previous example, it will probably not get called.)

Likewise, you probably should avoid having a list of pointers. The list should store the objects directly. Try using std::list… practice with the language features is more important than practice implementing data structures.

Answer 2

Use the option #1 with a slight change; instead of returning a reference to the locally created object, return its copy.

i.e. return ret;

Most C++ compilers perform Return value optimization (RVO) to optimize away the temporary object created to hold a function's return value.

Answer 3

In general, you should never return a reference or a pointer. Instead, return a copy of the object or return a smart pointer class which owns the object. In general, use static storage allocation unless the size varies at runtime or the lifetime of the object requires that it be allocated using dynamic storage allocation.

As has been pointed out, your example of returning by reference returns a reference to an object that no longer exists (since it has gone out of scope) and hence are invoking undefined behavior. This is the reason you should never return a reference. You should never return a raw pointer, because ownership is unclear.

It should also be noted that returning by value is incredibly cheap due to return-value optimization (RVO), and will soon be even cheaper due to the introduction of rvalue references.