lo que Stanley entiende por “recursivo” es sólo que el operador se aplica a cada objeto devuelto hasta el el tipo devuelto es un puntero.
Lo que sucede aquí en el primer intento: screen::operator ->
devuelve un puntero. Por lo tanto, esta es la última llamada a un operator ->
que intenta el compilador. A continuación, resuelve el lado derecho del operador (p
) buscando un miembro en el tipo de puntaje devuelto (dummy
) con ese nombre.
Esencialmente, cada vez que el compilador encuentra la sintaxis aᵢ->b
en el código, que, esencialmente, se aplica el siguiente algoritmo:
- Es
aᵢ
del tipo de puntero? De ser así, resuelva el miembro b
de *aᵢ
y llame al (*aᵢ).b
.
- lo demás, tratar de resolver
aᵢ::operator ->
- En caso de éxito, establecer
aᵢ₊₁ = aᵢ::operator ->()
. Ir a 1.
- En caso de error, emita un error de compilación.
estoy en apuros para llegar a un pequeño ejemplo, donde un significativo cadena de invocaciones operator ->
siquiera tiene sentido. Probablemente, el único uso real sea cuando escribe una clase de puntero inteligente.
Sin embargo, el siguiente ejemplo de juguete al menos compila y arroja un número. Pero no aconsejaría realmente escribir dicho código. Rompe la encapsulación y hace llorar a los gatitos.
#include <iostream>
struct size {
int width;
int height;
size() : width(640), height(480) { }
};
struct metrics {
size s;
size const* operator ->() const {
return &s;
}
};
struct screen {
metrics m;
metrics operator ->() const {
return m;
}
};
int main() {
screen s;
std::cout << s->width << "\n";
}
¿Dónde se dice que se "aplica recursivamente"? –
No, no estoy de acuerdo con que su ejemplo funcione como se esperaba, el -> opertor es solo una llamada de función en esencia, ¿por qué debería profundizarse? Si lo hiciera así, ¿cómo controlaría a qué nivel detener la desreferenciación y haría que la herencia y el polimorfismo fueran aún más complicados de lo que ya es – EdChum
C++ Primer, cuarta edición Por Stanley B. Lippman, sección 14.6 último párrafo. – user1232138