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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 460 — #498
✐
Capítulo 15. Polimorfismo y Funciones virtuales
de retorno la función de la clase base es la única razón que hace que esto compile. De
esta forma el acuerdo se cumple totalmente: eats() siempre devuelve un puntero
a PetFood.
Si se piensa de forma polimórfica lo anterior no parece necesario. ¿Por qué no
simplemente se hacen upcast de todos los tipos retornados a PetFood* como lo hace
Bird::eats() Normalmente esa es una buena solución, pero al final del main()
se puede ver la diferencia: Cat::eats() puede devolver el tipo exacto de PetFood,
mientras que al valor retornado por Bird::eats() hay que hacerle un downcast
al tipo exacto.
Devolver el tipo exacto es un poco más general y además no pierde la información
específica de tipo debida al upcast automático. Sin embargo, devolver un tipo de
la clase base generalmente resuelve el problema por lo que esto es una característica
bastante específica.
15.10. funciones virtuales y constructores
Cuando se crea un objeto que contiene funciones virtuales, su VPTR debe ser inicializado
para apuntar a la correcta VTABLE. Esto debe ser hecho antes de que exista
la oportunidad de llamar a una función virtual. Como se puede adivinar, debido a
que el constructor tiene el trabajo de traer a la existencia al objeto, también será trabajo
del constructor inicializar el VPTR. El compilador de forma secreta añade código
al principio del constructor para inicializar el VPTR. Y como se describe en el capítulo
14, si no se crea un constructor de una clase de forma explícita, el compilador
genera uno de forma automática. Si la clase tiene funciones virtuales, el constructor
incluirá el código apropidado para la inicialización del VPTR. Esto tiene varias
consecuencias.
La primera concierne a la eficiencia. La razón de que existan funciones inline
es reducir la sobrecarga que produce llamar a funciones pequeñas. Si C++ no
proporciona funciones inline, el preprocesador debe ser usado para crear estas
"macros". Sin embargo, el preprocesador no tiene los conceptos de accesos o clases,
y además no puede ser usado para crear macros con funciones miembro. Además,
con los constructores que deben tener código oculto insertado por el compilador, una
macro del preprocesador no funcionaría del todo.
Hay que estar precavidos cuando se estén buscando agujeros de eficiencia porque
el compilador está insertando código oculto en los constructores. No sólo hay que
inicializar el VPTR, también hay que comprobar el valor de this (en caso de que el
operador new devuelva cero), y llamar al constructor de la clase base. Todo junto, éste
código puede tener cierto impacto cuando se pensaba que era una simple función
inline. En particular, el tamaño del constructor puede aplastar al ahorro que se
consigue al reducir la sobrecarga en las llamadas. Si se hacen un monton de llamadas
a constructores inline, el tamaño del código puede crecer sin ningún beneficio en la
velocidad.
Cuando esté afinando el código recuerde considerar el quitar los constructores en
línea.
15.10.1. Orden de las llamadas a los constructores
La segunda faceta interesante de los constructores y las funciones virtuales tiene
que ver con el orden de las llamadas a los constructores y el modo en que las
llamadas virtuales se hacen dentro de los constructores.
460
✐
✐
✐
✐