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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 153 — #191
✐
4.3. El objeto básico
ticamente se asegura de que realizará esa declaración por medio de la inclusión de
un fichero de cabecera. Además, si también incluye el mismo fichero de cabecera en
el mismo lugar donde se defines las funciones, el compilador verificará que las declaraciones
del archivo cabecera y las definiciones coinciden. Puede decirse entonces
que, de algún modo, los ficheros de cabecera se vuelven un repositorio de validación
de funciones y permiten asegurar que las funciones se usan de modo consistente en
todas las unidades de traducción del proyecto.
Obviamente, las funciones globales se pueden seguir declarando a mano en aquellos
lugares en las que se definen y usan (Sin embargo, esta práctica es tan tediosa
que está en desuso.) De cualquier modo, las estructuras siempre se deben declarar
antes de ser usadas y el mejor lugar para esto es un fichero de cabecera, exceptuando
aquellas que queremos esconder intencionalmente en otro fichero.
Se puede ver que todas las funciones miembro (métodos) tienen casi la misma
forma que sus versiones respectivas en C. Las únicas diferencias son su ámbito de
resolución y el hecho de que el primer argumento ya no aparece explícito en el prototipo
de la función. Por supuesto que sigue ahí ya que la función debe ser capaz de
trabajar sobre una variable struct en particular. Sin embargo, fíjese también que,
dentro del método, la selección de esta estructura en particular también ha desaparecido!
Así, en lugar de decir s->size = sz; ahora dice size = sz; eliminando
el tedioso s-> que en realidad no aportaba nada al significado semántico de lo que
estaba escribiendo. Aparentemente, el compilador de C++ está realizando estas tareas
por el programador. De hecho, está tomando el primer argumento «secreto» (la
dirección de la estructura que antes tenía que pasar a mano) y aplicándole el selector
de miembro (->) siempre que escribe el nombre de uno de los datos miembro. Eso
significa que, siempre y cuando esté dentro de la definición de una método de una
estructura puede hacer referencia a cualquier otro miembro (incluyendo otro método)
simplemente dando su nombre. El compilador buscará primero en los nombres
locales de la estructura antes de buscar en versiones más globales de dichos nombres.
El lector podrá descubrir que esta característica no sólo agiliza la escritura del
código, sino que también hace la lectura del mismo mucho más sencilla.
Pero qué pasaría si, por alguna razón, quisiera hacer referencia a la dirección de
memoria de la estructura. En la versión en C de la librería ésta se podía obtener
fácilmente del primer argumento de cualquier función. En C++ la cosa es más consistente:
existe la palabra reservada this que produce la dirección de la variable
struct actual. Es el equivalente a la expresión s de la versión en C de la librería. De
modo que, podremos volver al estilo de C escribiendo
this->size = Size;
El código generado por el compilador será exactamente el mismo por lo que no
es necesario usar this en estos casos. Ocasionalmente, podrá ver por ahí código
dónde la gente usa this en todos sitios sin agregar nada al significado del código
(esta práctica es indicio de programadores inexpertos). Por lo general, this no se usa
muy a menudo pero, cuando se necesite siempre estará allí (en ejemplos posteriores
del libro verá más sobre su uso).
Queda aún un último tema que tocar. En C, se puede asignar un void * a cualquier
otro puntero, algo como esto:
int i = 10;
void* vp = &i; // OK tanto en C como en C++
int* ip = vp; // óSlo aceptable en C
153
✐
✐
✐
✐