Nunca se puede saber la cantidad máxima de almacenamiento que se necesitará para una CStash, por eso la memoria a la que apuntan los elementos de storage se asigna desde el montículo (heap) ^[47]. El montículo es un gran bloque de memoria que se utiliza para asignar en pequeños trozos en tiempo de ejecución. Se usa el heap cuando no se conoce de antemano la cantidad de memoria que necesitará el programa que está escribiendo. Por ejemplo, eso ocurre en un programa en el que sólo en el momento de la ejecución se sabe si se necesia memoria para 200 variables Avión o para 20. En C Estándar, las funciones para asignación dinámica de memoria incluyen malloc(), calloc(), realloc() y free(). En lugar de llamadas a librerías, C++ cuenta con una técnica más sofisticada (y por lo tanto más fácil de usar) para tratar la memoria dinámica. Esta técnica está integrada en el lenguaje por medio de las palabras reservadas new y delete.

La función inflate() usa new para obtener más memoria para la CStash. En este caso el espacio de memoria sólo se amplia y nunca se reduce. assert() garantiza que no se pase un número negativo como argumento a inflate() como valor de incremento. La nueva cantidad de elmentos que se podrán almacenar (una vez se haya terminado inflate()) se determina en la variable newQuantity que se multiplica por el número de bytes que ocupa cada elemento, para obtener el nuevo número total de bytes de la asignación en la variable newBytes. Dado que se sabe cuántos bytes hay que copiar desde la ubicación anterior, oldBytes se calcula usando la cantidad antigua de bytes (quantity).

La petición de memoria ocurre realmente en la expresión-new que involucra la palabra reservada new:

new unsigned char[newBytes];

La forma general de una expresión-new es:

new Tipo;

donde Tipo describe el tipo de variable para la cual se solicita memoria en el montículo. Dado que en este caso, se desea asignar memoria para un array de unsigned char de newBytes elementos, eso es lo que aparece como Tipo. Del mismo modo, se puede asignar memoria para algo más simple como un int con la expresión:

new int;

y aunque esto se utiliza muy poco, demuestra que la sintaxis es consistente.

Una expresión-new devuelve un puntero a un objeto del tipo exacto que se le pidió. De modo que con new Tipo se obtendrá un puntero a un objeto de tipo Tipo, y con new int obtendrá un puntero a un int. Si quiere un nuevo array de unsigned char la expresión devolverá un puntero al primer elemento de dicho array. El compilador verificará que se asigne lo que devuelve la expresión-new a una variable puntero del tipo adecuado.

Por supuesto, es posible que al pedir memoria, la petición falle, por ejemplo, si no hay más memoria libre en el sistema. Como verá más adelante, C++ cuenta con mecanismos que entran en juego cuando la operación de asignación de memoria no se puede satisfacer.

Una vez que se ha obtenido un nuevo espacio de almacenamiento, los datos que estaban en el antiguo se deben copiar al nuevo. Esto se hace, nuevamente, en un bucle, utilizando la notación de índexado de arrays, copiando un byte en cada iteración del bucle. Una vez finalizada esta copia, ya no se necesitan los datos que están en el espacio de almacenamiento original por lo que se pueden liberar de la memoria para que otras partes del programa puedan usarlo cuando lo necesiten. La palabra reservada delete es el complemento de new y se debe utilizar sobre todas aquellas variables a las cuales se les haya asignado memoria con new. (Si se olvida de utilizar delete esa memoria queda in-utilizable. Si estas fugas de memoria (memory leak) son demasiado abundantes, la memoria disponible se acabará.) Existe una sintaxis especial cuando se libera un array. Es como si recordara al compilador que ese puntero no apunta sólo a un objeto, sino a un array de objetos; se deben poner un par de corchetes delante del puntero que se quiere liberar:

delete []myArray;

Una vez liberado el antiguo espacio de almacenamiento, se puede asignar el puntero del nuevo espacio de memoria al puntero storage, se actualiza quantity y con eso inflate() ha terminado su trabajo.

En este punto es bueno notar que el administrador de memoria del montículo> es bastante primitivo. Nos facilita trozos de memoria cuando se lo pedimos con new y los libera cuando invocamos a delete. Si un programa asigna y libera memoria muchas veces, terminaremos con un montículo fragmentado, es decir un montículo en el que si bien puede haber memoria libre utilizable, los trozos de memoria están divididos de tal modo que no exista un trozo que sea lo suficientemente grande para las necesidades concretas en un momento dado. Lamentablemente no existe una capacidad inherente del lenguaje para efectuar defragmentaciones del montículo. Un defragmentador del montículo complica las cosas dado que tiene que mover pedazos de memoria, y por lo tanto, hacer que los punteros dejen de apuntar a valores válidos. Algunos entornos operativos vienen con este tipo de facilidades pero obligan al programador a utilizar manejadores de memoria especiales en lugar de punteros (estos manipuladores se pueden convertir temporalmente en punteros una vez bloqueada la memoria para que el defragmentador del montículo no la modifique). También podemos construir nosotros mismos uno de estos artilugios, aunque no es una tarea sencilla.

Cuando creamos una variable en la pila en tiempo de compilación, el mismo compilador es quien se encarga de crearla y liberar la memoria ocupada por ella automáticamente. Conoce exactamente el tamaño y la duración de este tipo de variables dada por las reglas de ámbito. Sin embargo, en el caso de las variables almacenadas dinámicamente, el compilador no poseerá información ni del tamaño requerido por las mismas, ni de su duración. Esto significa que el compilador no puede encargarse de liberar automáticamente la memoria ocupada por este tipo de variables y de aquí que el responsable de esta tarea sea el programador (o sea usted). Para esto se debe utilizar delete, lo cual le indica al administrador del montículo que ese espacio de memoria puede ser utilizado por próximas llamadas a new. En nuestra librería de ejemplo, el lugar lógico para esta tarea es la función cleanup() dado que allí es dónde se deben realizar todas las labores de finalización de uso del objeto.

Para probar la librería se crean dos Cstash, uno que almacene enteros y otro para cadenas de 80 caracteres:

//: C04:CLibTest.cpp
//{L} CLib
// Test the C-like library
#include "CLib.h"
#include <fstream>
#include <iostream>
#include <string>
#include <cassert>
using namespace std;

int main() {
  // Define variables at the beginning
  // of the block, as in C:
  CStash intStash, stringStash;
  int i;
  char* cp;
  ifstream in;
  string line;
  const int bufsize = 80;
  // Now remember to initialize the variables:
  initialize(&intStash, sizeof(int));
  for(i = 0; i < 100; i++)
    add(&intStash, &i);
  for(i = 0; i < count(&intStash); i++)
    cout << "fetch(&intStash, " << i << ") = "
         << *(int*)fetch(&intStash, i)
         << endl;
  // Holds 80-character strings:
  initialize(&stringStash, sizeof(char)*bufsize);
  in.open("CLibTest.cpp");
  assert(in);
  while(getline(in, line))
    add(&stringStash, line.c_str());
  i = 0;
  while((cp = (char*)fetch(&stringStash,i++))!=0)
    cout << "fetch(&stringStash, " << i << ") = "
         << cp << endl;
  cleanup(&intStash);
  cleanup(&stringStash);
} ///:~

Dado que debemos respetar la sintaxis de C, todas las variables se deben declarar al comienzo de main(). Obviamente, no nos podemos olvidar de inicializar todas las variables Cstash más adelante en el bloque main(), pero antes de usarlas, llamando a initialize(). Uno de los problemas con las librerías en C es que uno debe asegurarse de convencer al usuario de la importancia de las funciones de inicialización y destrucción. ¡Habrá muchos problemas si estas funciones se omiten! Lamentablemente 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.

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 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.