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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 414 — #452
✐
Capítulo 14. Herencia y Composición
orprendido ¡este mecanismo de comprobación de tipos seguro es gratuito, en
push(), peek() y pop! Al compilador se le proporciona información extra acerca de
los tipos y éste lo utiliza en tiempo de compilación, pero las funciones son inline y
no es necesario ningún código extra.
La ocultación de nombres entra en acción en la función push() que tiene la signatura
diferente: la lista de argumentos. Si se tuviesen dos versiones de push() en la
misma clase, tendrían que ser sobrecargadas, pero en este caso la sobrecarga no es
lo que deseamos porque todavía permitiría pasar cualquier tipo de puntero a push
como void *. Afortunadamente, C++ esconde la versión push (void *) en la clase base
en favor de la nueva versión que es definida en la clase derivada, de este modo, solo
se permite utilizar la función push() con punteros a String en StringStack.
Ahora podemos asegurar que se conoce exactamente el tipo de objeto que esta
en el contenedor, el destructor funcionará correctamente y problema esta resuelto -
o al menos, un parte del procedimiento. Si utiliza push( ) con un puntero a String en
StringStack, entonces (según el significado de StringStack) también se esta pasando
el puntero a StringStack. Si utiliza pop(), no solo consigue puntero, sino que a la vez
el propietario. Cualquier puntero que se haya dejado en StringStack será borrado
cuando el destructor sea invocado. Puesto que siempre son punteros a Strings y la
declaración delete esta funcionando con punteros a String en vez de punteros a void,
la destrucción se realiza de forma adecuada y todo funciona correctamente.
Esto es una desventaja: esta clase solo funciona con punteros de cadenas. Si se
desea un Stack que funcione con cualquier variedad de objetos, se debe escribir una
nueva versión de la clase que funcione con ese nuevo tipo de objeto. Esto puede
convertirse rápidamente en una tarea tediosa, pero finalmente es resulta utilizando
plantillas como se vera en el capítulo 16.
Existen consideraciones adicionales sobre este ejemplo: el cambio de la interfaz
en Stack en el proceso de herencia. Si la interfaz es diferente, entonces StringStack
no es realmente un Stack, y nunca será posible usar de forma correcta un StringStack
como Stack. Esto hace que el uso de la herencia sea cuestionable en este punto; si
no se esta creando un StringStack del tipo Stack, entonces, porque hereda de él. Más
adelante, sen este mismo capítulo se mostrará una versión más adecuada.
14.5. Funciones que no heredan automáticamente
No todas las funciones son heredadas automáticamente desde la clase base a la
clase derivada. Los constructores y destructores manejan la creación y la destrucción
de un objeto y sólo ellos saben que hacer con los aspectos de un objeto en sus
clases particulares y por ello los constructores y destructores inferiores de la jerarquía
deben llamarlos. Así, los constructores y destructores no se heredan y deben ser
creados específicamente en cada clase derivada.
Además, operator= tampoco se hereda porque realiza una acción parecida al
constructor. Esto es, sólo porque conoce como asignar todos los miembros de un
objeto, la parte izquierda del = a la parte derecha del otro objeto, no significa que la
asignación tendrá el mismo significado después de la herencia.
En la herencia, estas funciones son creadas por el compilador si no son creadas
por usted. (Con constructores, no se pueden crear constructores para que el compilador
cree el constructor por defecto y el constructor copia.) Esto fue brevemente
descrito en el capítulo 6. Los constructores creados se usan en inicialización de sus
miembros y la creación del operator= usa la asignación de los miembros. A continuación,
un ejemplo de las funciones que son creadas por el compilador.
414
✐
✐
✐
✐