sencillos - ¿Por qué no puedes sobrecargar el ''.'' operador en C++?

sobrecarga de operadores relacionales

Question

Sería muy útil poder sobrecargar el. operador en C ++ y devolver una referencia a un objeto.

Puede sobrecargar operator-> y operator* pero no operator.

¿Hay alguna razón técnica para esto?

Answer 1

Es muy fácil de entender, si va a través del mecanismo interno de la invocación de la función del operador, decir un complejo de clases puede tener dos miembros r para la parte real y yo para la parte imaginaria. Diga Complex C1 (10,20), C2 (10,2) // asumimos que ya hay un constructor de dos argumentos dentro de la clase. Ahora bien, si escribe C1 + C2 como una declaración, entonces el compilador intentará encontrar la versión sobrecargada del operador + en el número complejo. Ahora suponemos que sobrecargamos el operador +, por lo que C1 + C2 traducido internamente como c1.operator + (c2) Ahora supongamos por el tiempo que los seres pueden sobrecargar ''.'' operador. así que ahora piense en seguir la llamada C1.disp () // mostrar el contenido de un objeto complejo Ahora intente representar como una representación interna C1.operator. (------) , cosas completamente desordenadas creadas. Esa es la razón por la cual no podemos sobrecargar ''.'' operador

Answer 2

Stroustrup tiene una respuesta para esta pregunta :

Operador (punto) podría, en principio, sobrecargarse utilizando la misma técnica que para ->. Sin embargo, hacerlo puede llevar a preguntas sobre si una operación está destinada a la sobrecarga del objeto. o un objeto al que hace referencia Por ejemplo:

class Y {
public:
    void f();
    // ...
};
class X {   // assume that you can overload .
    Y* p;
    Y& operator.() { return *p; }
    void f();
    // ...
};
void g(X& x)
{
    x.f();  // X::f or Y::f or error?
}

Este problema se puede resolver de varias maneras. En el momento de la estandarización, no era obvio qué camino sería el mejor. Para más detalles, ver D & E.

Answer 3

Stroustrup dijo que C ++ debe ser un lenguaje extensible, pero no mutable.

El operador de punto (acceso de atributo) se consideraba demasiado cercano al núcleo del lenguaje para permitir la sobrecarga.

Ver El diseño y la evolución de C ++ , página 242, sección 11.5.2 Referencias inteligentes .

Cuando decidí permitir la sobrecarga del operador -> , naturalmente consideré si el operador . podría estar sobrecargado de manera similar.

En ese momento, consideré concluyentes los siguientes argumentos: si obj es un objeto de clase, obj.m tiene un significado para cada miembro m de la clase de ese objeto. Intentamos no hacer que el lenguaje sea mutable redefiniendo las operaciones integradas (aunque esa regla se infringe para = fuera de la necesidad extrema, y ​​para unary & ).

Si permitimos la sobrecarga de . para una clase X , no podríamos acceder a miembros de X por medios normales; tendríamos que usar un puntero y -> , pero -> y & también podrían haber sido redefinidos. Yo quería un lenguaje extensible, no mudable.

Estos argumentos son importantes, pero no concluyentes. En particular, en 1990, Jim Adcock propuso permitir la sobrecarga del operador . exactamente la forma en que el operador -> es.

El "yo" en esta cita es Bjarne Stroustrup. No puedes ser más autoritario que eso.

Si realmente quieres entender C ++ (como en "por qué es así"), deberías leer este libro.

Answer 4

Vea esta cita de Bjarne Stroustrup :

Operador (punto) podría, en principio, sobrecargarse utilizando la misma técnica que para ->. Sin embargo, hacerlo puede llevar a preguntas sobre si una operación está destinada a la sobrecarga del objeto. o un objeto al que hace referencia Por ejemplo:

class Y {
public:
    void f();
    // ...
};

class X {    // assume that you can overload .
    Y* p;
    Y& operator.() { return *p; }
    void f();
    // ...
};

void g(X& x)
{
    x.f();    // X::f or Y::f or error?
}

Este problema se puede resolver de varias maneras. En el momento de la estandarización, no era obvio qué camino sería el mejor. Para obtener más detalles, vea El diseño y la evolución de C ++ .