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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 148 — #186
✐
Capítulo 4. Abstracción de Datos
tablemente el usuario no siempre se preguntará si la inicialización y el limpiado de
los objetos son obligatorios. Ellos le darán importancia a lo que ellos quieren hacer
y no nos darán tanta importancia a nosotros (el programador de la librería) cuando
les digamos «¡Hey! ¡espera un poco! ¡Debes hacer esto primero!». Otro problema que
puede presentarse es el hecho de que algunos usuarios quieran inicializar los elementos
(datos internos) de una estructura por su cuenta. En C no hay un mecanismo
para prevenir este tipo de conductas (más presagios de los temás que vendrán...).
La intStash se va llenando con enteros mientras que el stringStash se va
llenando con arrays de caracteres. Estos arrays de caracteres son producidos leyendo
el archivo fuente CLibTest.cpp y almacenando las líneas de este archivo en
el string line. Obtenemos la representación «puntero a carácter» de line con el
método c_str().
Una vez cargados los Stash ambos se muestran en pantalla. intStash se imprime
usando un bucle for en el cual se usa count() para determinar la cantidad de
elementos. El stringStash se muestra utilizando un bucle while dentro del cual
se va llamando a fetch(). Cuando esta función devuelve cero se rompe el bucle ya
que esto significará que se han sobrepasado los límites de la estructura.
El lector también pudo haber visto un molde adicional en la línea:
cp = (char*)fetch(&stringStash, i++)
Esto se debe a la comprobación estricta de tipos en C++, que no permite asignar
un void * a una variable de cualquier tipo, mientras que C sí lo hubiera permitido.
4.1.2. Malas suposiciones
Antes de abordar los problemas generales de la creación de una librería C, discutiremos
otro asunto importante que se debe tener claro. Fíjese que el archivo de
cabecera CLib.h debe incluirse en cada archivo fuente que haga referencia al tipo
CStash ya que el compilador no puede adivinar qué aspecto tiene la estructura. Sin
embargo, sí puede adivinar el aspecto de una función. Aunque eso pueda parecer
una ventaja, veremos que en realidad, es un grave problema de C.
Aunque siempre debería declarar las funciones incluyendo un archivo de cabecera,
en C las declaraciones de funciones no son esenciales. En este lenguaje (pero no
en C++), es posible llamar a una función que no ha sido declarada. Un buen compilador
seguramente avisará de que deberíamos declarar la función antes de usarla,
pero nos permitirá seguir dado que no es obligatorio hacerlo en C estándar. Esta es
una práctica peligrosa ya que el compilador puede asumir que una función que ha
sido llamada con un int como argumento, tenga un int como argumento cuando, en
realidad, es un float. Como veremos, esto puede producir errores que pueden ser
muy difíciles de depurar.
Se dice que cada archivo de implementación C (los archivos de extensión .c) es
una unidad de traducción (translation unit). El compilador se ejecuta independientemente
sobre cada unidad de traducción ocupándose, en ese momento, solamente
en ese archivo. Por eso, la información que le demos al compilador por medio de los
archivos de cabecera es muy importante dado que determina la forma enq que ese
archivo se relaciona con las demás partes del programa. Por eso motivo, las declaraciones
en los archivos de cabecera son particularmente importantes dado que, en
cada lugar que se incluyen, el compilador sabrá exactamente qué hacer. Por ejemplo,
si en un archivo de cabecera tenemos la declaración void func(float) , si
148
✐
✐
✐
✐