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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 149 — #187
✐
4.2. ¿Qué tiene de malo
llamamos a func() con un int como argumento, el compilador sabrá que deberá
convertir el int a float antes de pasarle el valor a la función (a esto se le llama promoción
de tipos). Sin la declaración, el compilador asumiría que la función tiene la forma
func(int), no realizaría la promoción y pasaría, por lo tanto, datos incorrectos a la
función.
Para cada unidad de traducción, el compilador crea un archivo objeto, de extensión
.o, .obj o algo por el estilo. Estos archivos objeto, junto con algo de código de
arranque se unens por el enlazador(linker) para crear el programa ejecutable. Todas
las referencias externas se deben resolver en la fase de enlazado. En archivos como
CLibTest.cpp, se declaran funciones como initialize() y fetch() (o sea, se
le informa al compilador qué forma tienen estas funciones), pero no se definen. Están
definidas en otro lugar, en este caso en el archivo CLib.cpp. De ese modo, las
llamadas que se hacen en CLibTest.cpp a estas funciones son referencias externas.
Cuando se unen los archivos objeto para formar el programa ejecutable, el enlazador
debe, para cada referencia externa no resuelta, encontrar la dirección a la que hace
referencia y reemplazar cada referencia externa con su dirección correspondiente.
Es importante señalar que en C, estas referencias externas que el enlazador busca
son simples nombres de funciones, generalmente precedidos por un guión bajo. De
esta forma, la única tarea del enlazador es hacer corresponder el nombre de la función
que se llama, con el cuerpo (definición, código) de la función del archivo objeto,
en el lugar exacto de la llamada a dicha función. Si, por ejemplo, accidentalmente
hacemos una llamada a una función que el compilador interprete como func(int)
y existe una definición de función para func(float) en algún archivo objeto, el
enlazador verá _func en un lugar y _func en otro, por lo que pensará que todo está
bien. En la llamada a func() se pasará un int en la pila pero el cuerpo de la función
func() esperará que la pila tenga un float. Si la función sólo lee el valor de este dato
y no lo escribe, la pila no sufrirá datos. De hecho, el supuesto float leído de la pila
puede tener algo de sentido: la función seguirá funcionando aunque sobre basura,
y es por eso que los fallos originadas por esta clase de errores son muy difíciles de
encontrar.
4.2. ¿Qué tiene de malo
Somos seres realmente destinados a la adaptación, incluso a las que quizá no deberíamos
adaptarnos. El estilo de la librería CStash ha sido un modelo a seguir para
los programadores en C durante mucho tiempo. Sin embargo, si nos ponemos a examinarla
por un momento, nos daremos cuenta de que utilizar esta librería puede
resultar incómodo. Cuando la usamos debemos, por ejemplo, pasar la dirección de
la estructura a cada función de la librería. Por eso, cuando leemos el código, los mecanismos
de la librería se mezclan con el significado de las llamadas a las funciones,
lo cual dificulta la comprecsión del programa.
Sin embargo, uno de los mayores obstáculos al trabajar con librerías en C es el
problema llamado conflicto de nombres (name clashes). C trabaja con un único espacio
de nombres de funciones. Esto significa que, cuando el enlazador busca por el nombre
de una función, lo hace en una única lista de nombres maestra. Además, cuando
el compilador trabaja sobre una unidad de traducción, un nombre de función sólo
puede hacer referencia a una única función con ese nombre.
Supongamos que compramos dos librerías de diferentes proveedores y que cada
librería consta de una estructura que debe inicializar y destruir. Supongamos que cada
proveedor ha decidido nombrar a dichas operaciones initialize() y cleanup().
¿Cómo se comportaría el compilador si incluyéramos los archivos de cabecera
149
✐
✐
✐
✐