Esto es un poco subjetivo, creo; No estoy seguro de si la opinión será unánime (he visto muchos fragmentos de código donde se devuelven referencias).

De acuerdo con un comentario sobre esta pregunta que acabo de hacer, con respecto a la inicialización de referencias , devolver una referencia puede ser malo porque, [según tengo entendido], hace que sea más fácil no borrarlo, lo que puede provocar pérdidas de memoria.

Esto me preocupa, ya que he seguido ejemplos (a menos que esté imaginando cosas) y haya hecho esto en unos pocos lugares ... ¿He entendido mal? ¿Es malo? Si es así, ¿qué tan malvado?

Siento que debido a mi mezcla de punteros y referencias, combinado con el hecho de que soy nuevo en C ++, y la confusión total sobre qué usar cuando, mis aplicaciones deben ser una pérdida de memoria ...

Además, entiendo que el uso de punteros inteligentes / compartidos es generalmente aceptado como la mejor manera de evitar pérdidas de memoria.

En general, devolver una referencia es perfectamente normal y ocurre todo el tiempo.

Si te refieres a:

int& getInt() {
    int i;
    return i;  // DON'T DO THIS.
}

Eso es todo tipo de maldad. La pila asignada idesaparecerá y no te estás refiriendo a nada. Esto también es malo:

int& getInt() {
    int* i = new int;
    return *i;  // DON'T DO THIS.
}

Porque ahora el cliente finalmente tiene que hacer lo extraño:

int& myInt = getInt(); // note the &, we cannot lose this reference!
delete &myInt;         // must delete...totally weird and  evil

int oops = getInt(); 
delete &oops; // undefined behavior, we're wrongly deleting a copy, not the original

Tenga en cuenta que las referencias de valor siguen siendo solo referencias, por lo que todas las aplicaciones malvadas siguen siendo las mismas.

Si desea asignar algo que vive más allá del alcance de la función, use un puntero inteligente (o, en general, un contenedor):

std::unique_ptr<int> getInt() {
    return std::make_unique<int>(0);
}

Y ahora el cliente almacena un puntero inteligente:

std::unique_ptr<int> x = getInt();

Las referencias también están bien para acceder a cosas donde sabe que la vida útil se mantiene abierta en un nivel superior, por ejemplo:

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

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

Aquí sabemos que está bien devolver una referencia i_porque lo que sea que nos llame gestiona la vida útil de la instancia de clase, por i_lo que vivirá al menos ese tiempo.

Y, por supuesto, no hay nada malo con solo:

int getInt() {
   return 0;
}

Si el tiempo de vida debe dejarse en manos de la persona que llama, y ​​solo está calculando el valor.

Resumen: está bien devolver una referencia si la vida útil del objeto no terminará después de la llamada.

No. No, no, mil veces no.

Lo que es malo es hacer referencia a un objeto asignado dinámicamente y perder el puntero original. Cuando usted newobjeta, asume la obligación de tener una garantía delete.

Pero eche un vistazo, por ejemplo, operator<<que debe devolver una referencia, o

cout << "foo" << "bar" << "bletch" << endl ;

no funciona

Debe devolver una referencia a un objeto existente que no desaparecerá de inmediato y donde no tiene intención de transferir ninguna propiedad.

Nunca devuelva una referencia a una variable local o algo así, porque no estará allí para ser referenciada.

Puede devolver una referencia a algo independiente de la función, que no espera que la función de llamada asuma la responsabilidad de eliminar. Este es el caso de la operator[]función típica .

Si está creando algo, debe devolver un valor o un puntero (normal o inteligente). Puede devolver un valor libremente, ya que entra en una variable o expresión en la función de llamada. Nunca devuelva un puntero a una variable local, ya que desaparecerá.

Las respuestas no me parecen satisfactorias, así que agregaré mis dos centavos.

Analicemos los siguientes casos:

Uso erróneo

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

Esto obviamente es un error

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

Uso con variables estáticas

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

Esto es correcto, porque las variables estáticas existen durante toda la vida de un programa.

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

Esto también es bastante común cuando se implementa el patrón Singleton

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

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

}

Uso:

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

Operadores

Los contenedores de biblioteca estándar dependen en gran medida del uso de operadores que devuelven referencias, por ejemplo

T & operator*();

puede usarse en lo siguiente

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

Acceso rápido a datos internos.

Hay momentos en los que & se puede usar para acceder rápidamente a datos internos

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

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

con uso:

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

SIN EMBARGO, esto puede conducir a dificultades como esta:

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!

No es malo Al igual que muchas cosas en C ++, es bueno si se usa correctamente, pero hay muchas dificultades que debe tener en cuenta al usarlo (como devolver una referencia a una variable local).

Hay cosas buenas que se pueden lograr con él (como map [name] = "hello world")

"devolver una referencia es malo porque, simplemente, según tengo entendido, hace que sea más fácil no borrarla"

No es verdad. Devolver una referencia no implica semántica de propiedad. Es decir, solo porque haces esto:

Value& v = thing->getTheValue();

... no significa que ahora posee la memoria a la que se refiere v;

Sin embargo, este es un código horrible:

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

Si está haciendo algo como esto porque "no necesita un puntero en esa instancia", entonces: 1) simplemente desreferenciar el puntero si necesita una referencia, y 2) eventualmente necesitará el puntero, porque debe hacer coincidir un nuevo con una eliminación, y necesita un puntero para llamar a la eliminación.

Hay dos casos:

• referencia constante: buena idea, a veces, especialmente para objetos pesados ​​o clases proxy, optimización del compilador

• referencia no constante: una mala idea, a veces, rompe encapsulaciones

Ambos comparten el mismo problema: pueden señalar potencialmente objetos destruidos ...

Recomendaría usar punteros inteligentes para muchas situaciones en las que necesita devolver una referencia / puntero.

Además, tenga en cuenta lo siguiente:

Existe una regla formal: el estándar C ++ (sección 13.3.3.1.4 si está interesado) establece que un temporal solo puede vincularse a una referencia constante; si intenta utilizar una referencia no constante, el compilador debe marcar esto como un error.

No solo no es malo, a veces es esencial. Por ejemplo, sería imposible implementar el operador [] de std :: vector sin usar un valor de retorno de referencia.

Adición a la respuesta aceptada:

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

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

Yo diría que este ejemplo no está bien y debería evitarse si es posible. ¿Por qué? Es muy fácil terminar con una referencia colgante .

Para ilustrar el punto con un ejemplo:

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

entrando en la zona de peligro:

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

la referencia de retorno se usa generalmente en la sobrecarga de operadores en C ++ para objetos grandes, porque devolver un valor necesita una operación de copia (en la sobrecarga del perador, generalmente no usamos el puntero como valor de retorno)

Pero la referencia de retorno puede causar problemas de asignación de memoria. Debido a que una referencia al resultado se pasará de la función como una referencia al valor de retorno, el valor de retorno no puede ser una variable automática.

si desea usar referencias de retorno, puede usar un búfer de objeto estático. por ejemplo

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;
 }

de esta manera, puede usar la referencia de retorno de forma segura.

Pero siempre puede usar el puntero en lugar de la referencia para devolver el valor en functiong.

Creo que usar la referencia como valor de retorno de la función es mucho más sencillo que usar el puntero como valor de retorno de la función. En segundo lugar, siempre sería seguro utilizar una variable estática a la que se refiera el valor de retorno.

Lo mejor es crear un objeto y pasarlo como parámetro de referencia / puntero a una función que asigna esta variable.

Asignar un objeto en la función y devolverlo como referencia o puntero (sin embargo, el puntero es más seguro) es una mala idea debido a que libera memoria al final del bloque de funciones.

    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 
     }
  };

La función getPtr puede acceder a la memoria dinámica después de la eliminación o incluso a un objeto nulo. Lo que puede causar malas excepciones de acceso. En cambio, getter y setter deben implementarse y verificarse el tamaño antes de regresar.

La función como lvalue (también conocido como devolución de referencias no constantes) debe eliminarse de C ++. Es terriblemente poco intuitivo. Scott Meyers quería un min () con este comportamiento.

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

lo cual no es realmente una mejora en

setmin (a, b, 0);

Este último incluso tiene más sentido.

Me doy cuenta de que la función como lvalue es importante para las secuencias de estilo C ++, pero vale la pena señalar que las secuencias de estilo C ++ son terribles. No soy el único que piensa esto ... ya que recuerdo que Alexandrescu tenía un gran artículo sobre cómo hacerlo mejor, y creo que boost también ha tratado de crear un mejor método de E / S seguro.

Me encontré con un problema real donde realmente era malvado. Esencialmente, un desarrollador devolvió una referencia a un objeto en un vector. ¡¡¡Eso fue malo!!!

Los detalles completos sobre los que escribí en enero: http://developer-resource.blogspot.com/2009/01/pros-and-cons-of-returing-references.html

Sobre código horrible:

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

Entonces, de hecho, el puntero de memoria se perdió después del regreso. Pero si usa shared_ptr así:

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

La memoria no se pierde después del regreso y se liberará después de la asignación.