Is returning a reference ever a good idea?

We all know that returning a reference to a local variable is a bad idea. However, I'm wondering if it's ever really a good idea to a return a reference at all and if it's possible to determine some good rules about when or when not to do it.

My problem with returning a reference is that the calling function needs to care about the lifetime of an object that shouldn't be its responsibility. As a contrived example:

#include <vector>

const int& foo() {
  std::vector<int> v = {1, 2, 3, 4, 5};
  return v[0];
}

int main(int argc, const char* argv[])
{
  const int& not_valid = foo();
  return 0;
}

Here, the vector goes out of scope at the end of foo, destroying its contents and invalidating any references to its elements. vector::operator[] returns a reference to the element, and so when this reference is further returned out of foo, the reference in main is dangling. I don't believe the const reference will extend the lifetime here because it's not a reference to a temporary.

As I said, this is a contrived example and the writer of foo probably wouldn't be so silly to try and return v[0] as a reference. However, it's easy to see how returning a reference requires the caller to care about the lifetime of an object it doesn't own. Pushing an element into a vector copies it, so then the vector is responsible for it. This problem doesn't exist for passing a reference argument because you know the function will complete before the caller continues and destroys the object.

I can see that returning a reference allows some nice array-like syntax like v[0] = 5 - but what's so bad about having a member function like v.set(index, value)? At least with this we wouldn't be exposing the internal objects. I know there may also be a performance increase from returning a reference, but with RVO, Named RVO (NRVO), and move semantics it is either negligible or non-existent.

So I've been trying to imagine under which situations returning a reference is ever truly safe, but I can't get my head around all the different permutations of ownership semantics that it might involve. Are there any good rules on when to do this?

Note: I know a better way to deal with ownership in vectors is to use smart pointers, but then you get the same problem with a different object - who owns the smart pointer?

There are tons of good uses for returning a reference. One is, as you said, to emulate something like the native dereference operator:

struct Goo
{
    int & operator[](size_t i) { return arr[i]; }
    int & front()              { return arr[0]; }

    // etc.

private:
    int * arr;
};

Another use case is when you return a reference to a thing that was passed in. The typical example is a chainable operation like <<:

std::ostream & operator<<(std::ostream & os, Goo const & g)
{ 
    return os << g[3];
}

As a final example, here's a thread-safe global object:

Goo & get_the_object()
{
    static Goo impl;
    return impl;
}

References are an integral part of the language, and they may well be returned by a function call. As you said, it's important to understand the lifetime of objects, but that's always true and not a particular problem of returning references.

Personally, I like returning references to static variables when I want to implement the Singleton pattern

SomeClass& getTheSingleton()
{
    static SomeClass theInstance;
    return theInstance;
}

I dont have to write any logic involving whether or not some pointer is initialized, and it gives me some control over the order of static initialization

来源：https://stackoverflow.com/questions/13077979/is-returning-a-reference-ever-a-good-idea

标签

c++

reference

ownership