C++ por qué el operador de asignación debe devolver un const ref para evitar (a = b) = c

Question

Estoy leyendo un libro sobre C++ y más precisamente sobre la sobrecarga del operador.

El ejemplo es la siguiente:

const Array &Array::operator=(const Array &right) 
{ 
// check self-assignment 
// if not self- assignment do the copying 
return *this; //enables x=y=z 
} 

La explicación proporcionada por el libro de volver ref const en lugar de ref es evitar asignaciones tales como (x = y) = z. No entiendo por qué debemos evitar esto. Entiendo que x = y se evalúa primero en este ejemplo y dado que devuelve una referencia constante, la parte = z no se puede ejecutar. ¿Pero por qué?

Answer 1

(x=y) significa x.operator=(y), que devuelve el objeto x. Por lo tanto, (x=y)=z significa (x.operator=(y)).operator=(z). La expresión en pares establece x en y y devuelve x, y luego el bit externo establece x en z. No establece y en z como cabría esperar, y como lo hace la expresión x = y = z.

Este comportamiento es contrario a la intuición (todos deberían ser iguales después de la asignación, ¿no?); devolver una referencia constante lo hace imposible y evita el problema.

Answer 2

No hay necesidad de evitar esto, a menos que el libro esté dirigido a programadores que comúnmente escriben (x=y)=z cuando quieren decir x=y=z. En la práctica, nadie en su sano juicio escribe eso, por lo que la precaución es completamente innecesaria. También prohíbe algunos otros constructos escuetos, como (x=y).nonConstMember(), que casi nadie escribe, pero que podrían ser útiles en algunos contextos (aunque no deberían utilizarse en exceso).

@ybungalobill es correcto, consigue un mejor libro.

Answer 3

Por lo que sé, los operadores de asignación no devuelven referencias de referencias en C++ idiomático. Los tipos estándar tampoco devuelven referencias a const.

std::string a, b, c; 
(a = b).clear(); // no objection from compiler 

Todos mis operadores de asignación personalizados han devuelto una referencia no constante.

En caso de duda, consulte la Biblioteca estándar. No es perfecto, pero definitivamente hace cosas básicas como esta correctas.

Answer 4

Me gustaría ver el comportamiento de los tipos incorporados.

Al definir sus propios tipos, es preferible que los operadores se comporten de la misma manera que los tipos incorporados. Esto permite la fácil adopción de sus clases sin tener que profundizar en su código para ver por qué se comportan de manera diferente a lo esperado.

Así que si miramos los números enteros:

int main() 
{ 
    int x = 5; 
    int y = 6; 
    int z = 7; 

    (x = y) = z; 
    std::cout << x << " " << y << " " << z << "\n"; 
} 

Esto funciona con y sin cambios y X se asigna 7. En el código que cabe esperar de su operador de asignación para trabajar de la misma manera. La definición operador de asignación estándar:

Array& Array::operator=(Array const& rhs) 
{ 
    /* STUFF */ 
    return *this; 
} 

debe hacer eso muy bien (suponiendo/* * LA MATERIA/es correcta).

Answer 5

La única razón que puedo ver es que este libro fue escrito para explicar a los programadores de C++ a C (o por un autor cuya comprensión de C es mejor que la comprensión de C++). Porque para un programador en C, la expresión (x = y) = z no es válida para los tipos incorporados, y probablemente intente obtener el mismo comportamiento con sus tipos definidos por el usuario.

Sin embargo, C y C++ son idiomas diferentes, y en C++ la expresión (x = y) = z es válida incluso para tipos incorporados. Por lo tanto, si desea tener el mismo comportamiento para los tipos definidos por el usuario, debe devolver una referencia no constante en el operator =.

Le aconsejo que obtenga un mejor libro, uno que no haga la confusión entre C y C++. No son los mismos idiomas, incluso si provienen de una base común.