c++ - usa - politicas de devolucion de mercancia vendida

¿Por qué debería devolver algo por valor, ya que C++ tiene constantes referencias?

Question

Considera esta función:

Thing func(){
    return something;
}

Cada llamada a esta función, una copia de something se hace y se pasa a la persona que llama.

Mi pregunta es, ¿por qué no hacer esto ( cada vez que quiero devolver algo por valor)?

const Thing& func(){
    return something;
}

De esta manera, no nos arriesgamos a copiar something sin una razón para hacerlo. Si el cliente solo necesita "leer" de something , pero no "escribir" en él, una referencia constante puede hacer exactamente eso. Y si el cliente necesita una copia, simplemente puede asignar la referencia constante a una variable, por ejemplo:

Thing thing = func(); // the object is passed by const reference, and then copied.

Entonces, ¿hay alguna razón para simplemente devolver por valor?

Por cierto, no es que me importe tanto la optimización, es solo que no veo una razón para volver por el simple valor.

Pregunta de seguimiento: leyendo las respuestas, entiendo que hay ventajas y desventajas para cada método. ¿Hay un defecto? Por ejemplo, "por defecto a devolver por valor" ? ¿O es puramente basado en el caso específico?

Answer 1

Entonces, ¿hay alguna razón para simplemente devolver por valor?

Sí. Si está devolviendo una función de variable local, por ejemplo.

int compute(int a, int b)
{
    int result;
    // a lot of magic
    return result;
}

Si esa función fuera devolver una referencia a un result de cualquier tipo, sería un problema.

Aparte de eso, las variables locales de función de retorno con clase de clase "por valor" se pueden optimizar con elision de copia - el nombre de la optimización es NRVO. Y si esa optimización no se aplica, la semántica de movimiento recién introducida podría (aunque solo debes confiar en la copia de la elision, funciona bastante bien). Simplemente no hay incentivo para devolver una referencia en tales casos.

Además, no querrá devolver referencias si desea mantener las cosas en privado. ¿Por qué devolvería una referencia constante a una variable miembro privada en una función miembro pública? Indica que la variable miembro existe , información que el sitio de la llamada no tiene que saber. También considere la seguridad de los subprocesos: el return las variables por referencia podría llevar a una carrera de datos si el mismo objeto está siendo modificado por otro subproceso después de la return retorno.

¿O es puramente basado en el caso específico?

La mayoría de las veces volverá por valor, especialmente para funciones que no son miembros. Las funciones miembro pueden devolver referencias a miembros *, pero casi no hay escenarios en los que una función no miembro devuelva referencias. Solo debe devolver referencias cuando sepa que necesita (y lo que está haciendo).

* _{Y también solo si realmente lo necesitan .}

Answer 2

Porque si su objeto (por cualquier razón) fue creado en la pila de la función llamada, devolver y usar una referencia a ella es un comportamiento indefinido.

Con la devolución por valor, el compilador a veces puede optimizar la devolución y no hay referencias peligrosas. Con C ++ 11 y la semántica de movimiento, esto se lleva a un nuevo nivel.

No tiene sentido decir "siempre es mejor devolver por referencia que por valor", cada caso en el que se usa uno, debe considerarse por separado.

Answer 3

Si está devolviendo una variable local no estática, entonces debe devolver por valor, ya que se destruirá cuando la función regrese, haciendo que cualquier referencia a ella sea inválida. En ese caso, la copia a menudo puede ser reemplazada por un movimiento, o eliminada por completo.

Si estás devolviendo algo persistente, entonces tienes razón; en general, es mejor devolver una referencia y dejar que la persona que llama decida si se debe copiar. Pero puede haber otras razones, como la seguridad de subprocesos, para preferir la devolución por valor incluso en ese caso: al devolver una copia, el lector no puede acceder al objeto persistente mientras que otro subproceso puede estar modificándolo.