Devolviendo una referencia constante a un objeto en lugar de una copia

Question

Mientras refactoreo de algunos códigos encontré algunos métodos getter que devuelven una cadena std ::. Algo como esto, por ejemplo:

class foo 
{ 
private: 
    std::string name_; 
public: 
    std::string name() 
    { 
     return name_; 
    } 
}; 

Sin duda, el comprador sería mejor devolver un const std::string&? El método actual es devolver una copia que no es tan eficiente. ¿Devolvería una referencia const en su lugar causaría algún problema?

Answer 1

La única forma en que esto puede causar un problema es si la persona que llama almacena la referencia, en lugar de copiar la cadena, e intenta utilizarla después de que se destruye el objeto. De esta manera:

foo *pFoo = new foo; 
const std::string &myName = pFoo->getName(); 
delete pFoo; 
cout << myName; // error! dangling reference 

Sin embargo, dado que su función existente devuelve una copia, no se romperá ninguno de los códigos existentes.

Answer 2

Lo cambiaría para devolver const std :: string &. La persona que llama probablemente realice una copia del resultado de todos modos si no cambia todo el código de llamada, pero no presentará ningún problema.

Una posible arruga surge si tiene múltiples hilos llamando al nombre(). Si devuelve una referencia, pero luego cambia el valor subyacente, el valor de la persona que llama cambiará. Pero el código existente no parece seguro para subprocesos de todos modos.

Eche un vistazo a la respuesta de Dima para un posible problema relacionado pero poco probable.

Answer 3

Depende de lo que necesite hacer. Tal vez quiera que todos los que llaman modifiquen el valor devuelto sin cambiar la clase. Si devuelve la referencia constante que no volará.

Por supuesto, el siguiente argumento es que la persona que llama podría hacer su propia copia. Pero si sabe cómo se usará la función y sabe que sucede de todos modos, entonces quizás hacerlo le ahorrará un paso más adelante en el código.

Answer 4

Es concebible que pueda romper algo si la persona que llama realmente desea una copia, porque estaban a punto de alterar el original y deseaban conservar una copia. Sin embargo, es mucho más probable que, de hecho, solo devuelva una referencia constante.

Lo más fácil de hacer es probarlo y luego probarlo para ver si todavía funciona, siempre que tenga algún tipo de prueba que pueda ejecutar. De lo contrario, me centraría en escribir primero la prueba, antes de continuar con la refactorización.

Answer 5

Las probabilidades son bastante buenas de que el uso típico de esa función no se rompa si cambia a una referencia constante.

Si todo el código que llama a esa función está bajo su control, simplemente haga el cambio y vea si el compilador se queja.

Answer 6

Normalmente devuelvo const & a menos que no pueda. QBziZ da un ejemplo de dónde este es el caso. Por supuesto, QBziZ también afirma que std :: string tiene una semántica de copiar y escribir, que rara vez se cumple hoy en día, ya que COW implica una gran sobrecarga en un entorno de subprocesos múltiples. Al devolver const & le pones la responsabilidad a la persona que llama para hacer lo correcto con la cadena en su extremo. Pero dado que se trata de un código que ya está en uso, probablemente no debería cambiarlo a menos que el perfil demuestre que la copia de esta cadena está causando problemas de rendimiento masivo. Luego, si decides cambiarlo, deberás probar a fondo para asegurarte de que no hayas roto nada. Esperemos que los otros desarrolladores con los que trabajas no hagan cosas incompletas como en la respuesta de Dima.

Answer 7

¿Importa? Tan pronto como utilice un compilador de optimización moderno, las funciones que regresen por valor no implicarán una copia a menos que se requiera semánticamente.

Ver the C++ lite FAQ en esto.

Answer 8

Uno de los problemas para el regreso referencia constante sería si el código de usuario algo como:

const std::string & str = myObject.getSomeString() ; 

Con un retorno std::string, el objeto temporal permanecería vivo y unido a str str hasta que se sale del ámbito.

Pero, ¿qué ocurre con un const std::string &? Mi conjetura es que tendríamos una referencia constante a un objeto que podría morir cuando su objeto primario se desasigna:

MyObject * myObject = new MyObject("My String") ; 
const std::string & str = myObject->getSomeString() ; 
delete myObject ; 
// Use str... which references a destroyed object. 

Así que mi preferencia va a la devolución referencia constante (porque, de todos modos, estoy más cómodo con enviar una referencia que esperar que el compilador optimice el extra temporal), siempre que se respete el siguiente contrato: "si lo quiere más allá de la existencia de mi objeto, lo copian antes de la destrucción de mi objeto"

Answer 9

Algunas implementaciones de std :: string share memory con semántica copy-on-write, por lo que return-by-value puede ser casi tan eficiente como return-by-reference y no tiene que wo rry sobre los problemas de la vida útil (el tiempo de ejecución lo hace por usted).

Si está preocupado por el rendimiento, entonces compare (< = ¡¡¡no puedo hacer suficiente hincapié en eso) !!! Pruebe ambos enfoques y mida la ganancia (o la falta de ella). Si uno es mejor y realmente te importa, entonces úsalo. Si no, entonces prefiera el valor por valor de la protección que ofrece contra problemas de por vida mencionados por otras personas.

Ya sabes lo que dicen de hacer suposiciones ...

Answer 10

bien, así que las diferencias entre devolviendo una copia y devolver la referencia son:

• Rendimiento: Volviendo la referencia puede o no ser más rápido; depende de cómo se implemente std::string mediante la implementación de su compilador (como han señalado otros). Pero incluso si devuelve la referencia de la asignación después de la llamada a la función por lo general implica una copia, como en std::string name = obj.name();

• Seguridad: Volviendo la referencia puede o no causar problemas (de referencia) colgando. Si los usuarios de su función no saben lo que están haciendo, almacenar la referencia como referencia y usarla después de que el objeto que proporciona el suministro quede fuera del alcance, entonces hay un problema.

Si quieres que rápido y seguro uso impulso :: shared_ptr. Su objeto puede almacenar internamente la cadena como shared_ptr y devolver un shared_ptr. De esta forma, no se copiará el objeto en marcha y siempre es seguro (a menos que los usuarios extraigan el puntero sin procesar con get() y hagan cosas con él después de que su objeto salga del alcance).

Answer 11

En realidad, otra cuestión específicamente con la devolución de una cadena no por referencia, es el hecho de que std::string proporciona acceso a través de puntero a un interno const char* a través del método c_str(). Esto me ha causado muchas horas de dolor de cabeza de depuración. Por ejemplo, digamos que quiero obtener el nombre de foo y pasarlo a JNI para construir una jstring para pasar a Java más adelante, y que name() devuelve una copia y no una referencia. Yo podría escribir algo como esto:

foo myFoo = getFoo(); // Get the foo from somewhere. 
const char* fooCName = foo.name().c_str(); // Woops! foo.name() creates a temporary that's destructed as soon as this line executes! 
jniEnv->NewStringUTF(fooCName); // No good, fooCName was released when the temporary was deleted. 

Si la persona que llama se va a hacer este tipo de cosas, podría ser mejor usar algún tipo de puntero inteligente, o una referencia constante, o por lo menos tener un encabezado de comentario de advertencia desagradable sobre su método foo.name(). Menciono JNI porque los antiguos programadores de Java podrían ser particularmente vulnerables a este tipo de encadenamiento de métodos que, de lo contrario, puede parecer inofensivo.

Answer 12

Devolver una referencia a un miembro expone la implementación de la clase. Eso podría evitar el cambio de clase. Puede ser útil para métodos privados o protegidos en caso de que se necesite la optimización. What should a C++ getter return