Я считаю, что ответы неудовлетворительны, поэтому я добавлю свои два цента.

Разберем следующие случаи:

Ошибочное использование

int& getInt()
{
    int x = 4;
    return x;
}

Это очевидно ошибка

int& x = getInt(); // will refer to garbage

Использование со статическими переменными

int& getInt()
{
   static int x = 4;
   return x;
}

Это правильно, потому что статические переменные существуют на протяжении всего времени жизни программы.

int& x = getInt(); // valid reference, x = 4

Это также довольно часто при реализации паттерна Singleton.

Class Singleton
{
    public:
        static Singleton& instance()
        {
            static Singleton instance;
            return instance;
        };

        void printHello()
        {
             printf("Hello");
        };

}

Использование:

 Singleton& my_sing = Singleton::instance(); // Valid Singleton instance
 my_sing.printHello();  // "Hello"

Операторы

Стандартные библиотечные контейнеры сильно зависят от использования операторов, которые возвращают ссылку, например

T & operator*();

может использоваться в следующих

std::vector<int> x = {1, 2, 3}; // create vector with 3 elements
std::vector<int>::iterator iter = x.begin(); // iterator points to first element (1)
*iter = 2; // modify first element, x = {2, 2, 3} now

Быстрый доступ к внутренним данным

Бывают случаи, когда & может использоваться для быстрого доступа к внутренним данным

Class Container
{
    private:
        std::vector<int> m_data;

    public:
        std::vector<int>& data()
        {
             return m_data;
        }
}

с использованием:

Container cont;
cont.data().push_back(1); // appends element to std::vector<int>
cont.data()[0] // 1

ОДНАКО это может привести к такой ловушке:

Container* cont = new Container;
std::vector<int>& cont_data = cont->data();
cont_data.push_back(1);
delete cont; // This is bad, because we still have a dangling reference to its internal data!
cont_data[0]; // dangling reference!

Это не зло. Как и многие вещи в C ++, он хорош, если используется правильно, но есть много подводных камней, о которых вы должны знать при его использовании (например, возврат ссылки на локальную переменную).

С его помощью можно достичь хороших результатов (например, map [name] = "hello world")

"возвращать ссылку - зло, потому что просто [как я понимаю] это упрощает ее удаление"

Не правда. Возврат ссылки не подразумевает семантику владения. То есть просто потому, что вы делаете это:

Value& v = thing->getTheValue();

... не означает, что теперь вы владеете памятью, на которую указывает v;

Однако это ужасный код:

int& getTheValue()
{
   return *new int;
}

Если вы делаете что-то подобное, потому что «вам не нужен указатель в этом экземпляре ", тогда: 1) просто разыменуйте указатель, если вам нужна ссылка, и 2) вам в конечном итоге понадобится указатель, потому что вам нужно сопоставить новое с удалением, и вам нужен указатель для вызова удалять.

Есть два случая:

• const reference - хорошая идея, иногда, особенно для тяжелых объектов или прокси-классов, оптимизация компилятора

• неконстантная ссылка - плохая идея, иногда нарушает инкапсуляцию

Оба имеют одну и ту же проблему - потенциально могут указывать на уничтоженный объект ...

Я бы рекомендовал использовать интеллектуальные указатели во многих ситуациях, когда вам нужно вернуть ссылку / указатель.

Также обратите внимание на следующее:

Существует формальное правило - стандарт C ++ (раздел 13.3.3.1.4, если вам интересно) гласит, что временный объект может быть привязан только к константной ссылке - если вы попытаетесь использовать неконстантную ссылку, компилятор должен отметьте это как ошибку.

Это не только не зло, но и иногда необходимо. Например, было бы невозможно реализовать оператор [] для std :: vector без использования возвращаемого значения ссылки.

Дополнение к принятому ответу:

struct immutableint {
    immutableint(int i) : i_(i) {}

    const int& get() const { return i_; }
private:
    int i_;
};

Я бы сказал, что этот пример неприемлем, и его по возможности следует избегать. Почему? Очень легко получить висящую ссылку.

Чтобы проиллюстрировать это на примере:

struct Foo
{
    Foo(int i = 42) : boo_(i) {}
    immutableint boo()
    {
        return boo_;
    }  
private:
    immutableint boo_;
};

вход в опасную зону:

Foo foo;
const int& dangling = foo.boo().get(); // dangling reference!

ссылка на возврат обычно используется при перегрузке оператора в C ++ для большого объекта, потому что для возврата значения требуется операция копирования. (при перегрузке perator мы обычно не используем указатель в качестве возвращаемого значения)

Но обратная ссылка может вызвать проблему с выделением памяти. Поскольку ссылка на результат будет передана из функции как ссылка на возвращаемое значение, возвращаемое значение не может быть автоматической переменной.

если вы хотите использовать возврат ссылки, вы можете использовать буфер статического объекта. Например

const max_tmp=5; 
Obj& get_tmp()
{
 static int buf=0;
 static Obj Buf[max_tmp];
  if(buf==max_tmp) buf=0;
  return Buf[buf++];
}
Obj& operator+(const Obj& o1, const Obj& o1)
{
 Obj& res=get_tmp();
 // +operation
  return res;
 }

таким образом вы можете безопасно использовать возвращаемую ссылку.

Но вы всегда можете использовать указатель вместо ссылки для возврата значения в functiong.

Я думаю, что использование ссылки в качестве возвращаемого значения функции намного проще, чем использование указателя в качестве возвращаемого значения функции. Во-вторых, всегда было бы безопасно использовать статическую переменную, на которую ссылается возвращаемое значение.

Лучше всего создать объект и передать его как параметр ссылки / указателя функции, которая выделяет эту переменную.

Выделение объекта в функции и возврат его в качестве ссылки или указателя (тем не менее, указатель более безопасен) - плохая идея из-за освобождения памяти в конце функционального блока.

    Class Set {
    int *ptr;
    int size;

    public: 
    Set(){
     size =0;
         }

     Set(int size) {
      this->size = size;
      ptr = new int [size];
     }

    int& getPtr(int i) {
     return ptr[i];  // bad practice 
     }
  };

Функция getPtr может получить доступ к динамической памяти после удаления или даже к нулевому объекту. Что может вызвать исключения недопустимого доступа. Вместо этого должны быть реализованы геттер и сеттер, а размер должен быть проверен перед возвратом.

Функция как lvalue (также известная как возврат неконстантных ссылок) должна быть удалена из C ++. Это ужасно не интуитивно. Скотт Мейерс хотел мин () с таким поведением.

min(a,b) = 0;  // What???

что на самом деле не является улучшением

setmin (a, b, 0);

В последнем даже больше смысла.

Я понимаю, что функция lvalue важна для потоков в стиле C ++, но стоит отметить, что потоки в стиле C ++ ужасны. Я не единственный, кто так думает ... насколько я помню, у Александреску была большая статья о том, как добиться большего, и я считаю, что boost также попытался создать более безопасный метод ввода-вывода.

Я столкнулся с настоящей проблемой, когда действительно было зло. По сути, разработчик вернул ссылку на объект в векторе. Это было плохо !!!

Полная информация, о которой я писал в январе: http://developer-resource.blogspot.com/2009/01/pros-and-cons-of-returing-references.html

Об ужасном коде:

int& getTheValue()
{
   return *new int;
}

Итак, действительно, указатель памяти потерян после возврата. Но если вы используете shared_ptr вот так:

int& getTheValue()
{
   std::shared_ptr<int> p(new int);
   return *p->get();
}

Память не теряется при возврате и будет освобождена после назначения.