c++ - revista - ¿Por qué no referencia no const a objetos temporales?

revista ethos

Question

C ++ permite la asignación de objetos temporales solo a la referencia constante. No permitirá la asignación de objetos temporales como referencia.

Por ejemplo:

String& a = String("test");         // Error
const String& a = String("test");   // Ok

En todas partes busco este resultado, solo veo las siguientes respuestas

1. La modificación de objetos temporales causaría problemas no identificables
2. La modificación de objetos temporales es peligrosa
3. En algún punto del tiempo, se olvidará que es una variable temporal

Se ha dicho, los objetos temporales desaparecen después de la declaración. Entonces no debes modificarlo.

Si C ++ está tan interesado en bloquear la modificación de los objetos temporales, debería haber bloqueado la lectura de los objetos temporales ¿no? Si el objeto temporal se desvanece, entonces no tiene sentido leer los contenidos desde allí ¿no? Los casos posibles, donde puede ocurrir un derecho, también podrían involucrar la lectura también.

Entonces, ¿por qué ha estado bloqueando la escritura solo y permitiendo leer?

Por favor, dame una explicación de código de c ++ sólida.

Por favor, no desvíe la pregunta señalando algunas alternativas. Por favor, dame una respuesta sólida con el código por qué const int & está permitido e int & no está permitido para objetos temporales.

Uno dice && está ahí .. Mi pregunta es diferente ... OTRO decir, cambiar no se reflejará .. El cambio no se reflejará incluso cuando es const int & también. Ej: doble a; Const int & i = a; a ++; no afectará a i ..

Answer 1

Si C ++ está tan interesado en bloquear la modificación de los objetos temporales, debería haber bloqueado la lectura de los objetos temporales ¿no? Si el objeto temporal se desvanece, entonces no tiene sentido leer los contenidos desde allí ¿no?

No, leer el objeto es perfectamente sensato. Solo porque desaparecerá en el futuro no significa que leer los datos ahora no tenga sentido.

open_file(std::string("foo.txt"));

std::string("foo.txt") es un temporal que dejará de existir después de la llamada a open_file() pero los datos que contiene mientras existe realmente importan mucho.

Lo racional para no permitir que las temporarias se vinculen a referencias que no son const no es en realidad un problema fundamental con la escritura a los temporales. De hecho, en muchos lugares C ++ está perfectamente feliz de permitir que se modifiquen los temporales:

std::string("foo") = "bar";

Es solo que los diseñadores consideraron que causaría un número suficiente de problemas (probablemente debido a la expresión común de ''parámetros de salida'') sin habilitar nada de valor similar, por lo que simplemente tomaron una decisión de diseño para prohibir los enlaces temporales a no const referencias.

Con las referencias de rvalue ahora puede hacer exactamente lo que estaba prohibido antes:

void foo(int &&output) {
    output = 1;
}

foo(2);

Esto funciona bien, simplemente no es muy útil.

Answer 2

El caso original para no permitir referencias a los temporales fue para los parámetros de la función. Supongamos que esto fue permitido:

void inc(double& x)
{ x += 0.1; }

int i = 0;
inc(i);

¿Por qué no i cambian?

Answer 3

Hay una razón lógica para esto. Piensa, lo que realmente quieres en esta línea:

String& a = String("test");         // Error

Quieres una referencia. Una referencia se refiere al objeto al que hace referencia. Como una dirección del objeto (aunque las referencias no son direcciones, aclara la explicación de esta manera). De hecho, intentas obtener algo así como una dirección de String("test") . Pero ese objeto se desvanecerá justo en la siguiente línea, entonces, ¿cuál es el sentido de su dirección, si el objeto al que apunta no existe? ahora señala algo sin sentido ...

Con respecto a su segunda pregunta, ¿de qué sirve permitir objetos temporales juntos? Bueno, no hay nada de malo en eso. Tenga en cuenta, por ejemplo, el caso en el que desea pasar un objeto String a una función, que devuelve, por ejemplo, una cadena modificada correspondiente a esa cadena. Llamemos a la función DoubleString, así que en lugar de hacer

String s("hello ");
String s2 = DoubleString(s);

Puede usar una forma más corta y más conveniente

String s2 = DoubleString(String("hello "));

Ver, el objeto temporal String("hello ") sobrevive a toda la línea de código, lo que significa que está intacta cuando se envía a DoubleString y después de ella. Se destruye solo cuando toda la línea ha terminado.

Answer 4

Si tiene un objeto temporal que es muy costoso de copiar, puede preferir tomar un const& para ese objeto (por ejemplo, un retorno de función) en lugar de copiarlo en otra variable para usarlo más adelante. Tomar una referencia constante a un temporal extiende la vida de ese temporal al tiempo que la referencia viva, lo que le permite acceder a cualquier estado legible.

No se permite escribir porque, tan pronto como desee mutar una variable, también puede tener una instancia real en lugar de una temporal que tenga alias solo como referencia no const.