Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 454 — #492
✐
Capítulo 15. Polimorfismo y Funciones virtuales
Figura 15.4: Una nueva función virtual
Hay que hacer notar, que el compilador mapea la dirección de speak() en exactamente
el mismo lugar tanto en la VTABLE de Dog como en la de Pet. De igual
forma, si una clase Pug heredara de Dog, su versión de sit() ocuparía su lugar en
la VTABLE en la misma posición que en Dog. Esto es debido a que el compilador
genera un código que usa un simple desplazamiento numérico en la VTABLE para
seleccionar una función virtual, como se vio con el ejemplo en lenguaje ensamblador.
Sin importar el subtipo en concreto del objeto, su VTABLE está colocada de la misma
forma por lo que llamar a una función virtual se hará siempre del mismo modo.
En este caso, sin embargo, el compilador está trabajando sólo con un puntero a
un objeto de la clase base. La clase base tiene únicamente las funciones speak()
y name(), por lo que son a las únicas funciones a las que el compilador permitirá
acceder. ¿Cómo es posible saber que se está trabajando con un objeto Dog si sólo
hay un puntero a un objeto de la clase base El puntero podría apuntar a algún
otro tipo, que no tenga una función sit(). En este punto, puede o no tener otra
dirección a función en la VTABLE, pero en cualquiera de los casos, hacer una llamada
a una función virtual de esa VTABLE no es lo que se desea hacer. De modo que el
compilador hace su trabajo impidiendo hacer llamadas virtuales a funciones que
sólo existen en las clases derivadas.
Hay algunos poco comunes casos en los cuales se sabe que el puntero actualmente
apunta al objeto de una subclase específica. Si se quiere hacer una llamada a una
función que sólo exista en esa subclase, entonces hay que hacer un molde (cast) del
puntero. Se puede quitar el mensaje de error producido por el anterior programa
con:
((Dog *) p[1])->sit()
Aquí, parece saberse que p[1] apunta a un objeto Dog, pero en general no se
sabe. Si el problema consiste en averiguar el tipo exacto de todos los objetos, hay
que volver a pensar porque posiblemente no se estén usando las funciones virtuales
de forma apropiada. Sin embargo, hay algunas situaciones en las cuales el diseño
funciona mejor (o no hay otra elección) si se conoce el tipo exacto de todos los objetos,
por ejemplo aquellos incluidos en un contenedor genérico. Este es el problema de la
run time type identification o RTTI (identificación de tipos en tiempo de ejecución).
RTTI sirve para moldear un puntero de una clase base y "bajarlo" a un puntero de
una clase derivada ("arriba" y "abajo", en inglés "up" y "down" respectivamente, se
refieren al típico diagrama de clases, con la clase base arriba). Hacer el molde hacia
arriba (upcast) funciona de forma automática, sin coacciones, debido a que es completamente
seguro. Hacer el molde en sentido descendente (downcast) es inseguro
porque no hay información en tiempo de compilación sobre los tipos actuales, por lo
que hay que saber exactamente el tipo al que pertenece. Si se hace un molde al tipo
454
✐
✐
✐
✐