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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 462 — #500
✐
Capítulo 15. Polimorfismo y Funciones virtuales
el compilador genera código para ese constructor, se genera código para un constructor
de esa clase, no para la clase base, ni para una clase derivada (debido a que una
clase no puede saber quién la hereda). Por eso, el VPTR que use debe apuntar a la
VTABLE de esa clase. El VPTR permanece inicializado a la VTABLE para el resto de
vida del objeto a menos que no sea la última llamada al constructor. Si posteriormente
se llama a un constructor de una clase derivada, éste constructor pone el VPTR a
su VTABLE, y así hasta que el último constructor termine. El estado del VPTR es determinado
por el constructor que sea llamado en último lugar. Otra razón por la que
los constructores son llamados en orden desde la base al más derivado.
Pero mientras que toda esta serie de llamadas al constructor tiene lugar, cada
constructor ha puesto el VPTR a su propia VTABLE. Si se usa el mecanismo virtual
para llamar a funciones, producirá sólo una llamada a través de su propia VTABLE,
y no de la VTABLE del más derivado (como debería suceder después de que todos
los constructores hayan sido llamados). Además, muchos compiladores reconocen
cuando se hace una llamada a una función virtual dentro de un constructor, y realizan
una ligadura estática porque saben que la ligadura dinámica producirá una
llamada a una función local. En todo caso, no se conseguirán los resultados que se
podían esperar inicialmente de la llamada a una función virtual dentro de un constructor.
15.10.3. Destructores y destructores virtuales
No se puede usar la palabra reservada virtual con los constructores, pero los
destructores pueden, y a menudo deben, ser virtuales.
El constructor tiene el trabajo especial de iniciar un objeto poco a poco, primero
llamando al constructor base y después a los constructores derivados en el orden de
la herencia. De manera similar, el destructor tiene otro trabajo especial: desmontar un
objeto, el cual puede pertenecer a una jerarquía de clases. Para hacerlo, el compilador
genera código que llama a todos los destructores, pero en el orden inverso al que
son llamados en los constructores. Es decir, el constructor empieza en la clase más
derivada y termina en la clase base. ésta es la opción deseable y segura debido a que
el destructor siempre sabe que los miembros de la clase base están vivos y activos.
Si se necesita llamar a una función miembro de la clase base dentro del destructor,
será seguro hacerlo. De esta forma, el destructor puede realizar su propio limpiado,
y entonces llamar al siguiente destructor, el cual hará su propio limpiado, etc. Cada
destructor sabe de que clase deriva, pero no cuales derivan de él.
Hay que tener en cuenta que los constructores y los destructores son los únicos
lugares donde tiene que funcionar ésta jerarquía de llamadas (que es automáticamente
generada por el compilador). En el resto de las funciones, sólo esa función,
sea o no virtual, será llamada (y no las versiones de la clase base). La única forma
para acceder a las versiones de la clase base de una función consiste en llamar de
forma explicita a esa funciones.
Normalmente, la acción del destructor es adecuada. Pero ¿qué ocurre si se quiere
manipular un objeto a través de un puntero a su clase base (es decir, manipular al objeto
a través de su interfaz genérica) Este tipo de actividades es uno de los objetivos
de la programación orientada a objetos. El problema viene cuando se quiere hacer
un delete (eliminar) de un puntero a un objeto que ha sido creado en el montón
(>heap) con new. Si el puntero apunta a la clase base, el compilador sólo puede conocer
la versión del destructor que se encuentre en la clase base durante el delete.
¿Suena familiar Al fin y al cabo, es el mismo problema por las que fueron creadas
las funciones virtuales en el caso general. Afortunadamente, las funciones virtuales
462
✐
✐
✐
✐