La STL , acrónimo de Standard Template Library (Biblioteca Estándar de Plantillas), es, según Stroustrup, “un entorno-marco, formado por contenedores, iteradores y algoritmos, que resulta grande, sistemático, limpio, formalmente completo, comprehensible, elegante y eficiente”. Y además codificado en C++. Tantos elogios los recibe una biblioteca-marco de clases derivada de los trabajos de Dave Musser y Alex Stepanov en Hewlett Packard, cuyo propósito primero fue la producción de una estructura de código que permitiera la creación, en su seno, de algoritmos reutilizables. Tras un proceso iterativo de acoplamiento a Scheme, Ada y finalmente C++, en Noviembre de 1.993 el propio Stepanov junto con Meng Lee presentaron al Comité de Estandarización ANSI/ISO X3J16 la biblioteca, que fue aceptada como parte de la Biblioteca Estándar de C++ en julio de 1.994 e incorporada al borrador del estándar del lenguaje.

Bien, bien: parece que la STL es fabulosa, pero, tras esta exposición histórica, ¿para qué demonios sirve? Durante mucho tiempo se ha achacado a C++ la carencia de estructuras de datos con funcionalidad suficiente para procurar las bases de una deseada genericidad en la codificación. Y la STL proporciona justamente eso: un conjunto de estructuras de datos y de algoritmos que operan sobre aquéllas. Pero sobre todo procura, según Koenig, “un entorno conceptual que facilita a los usuarios la adición de sus propios algoritmos y estructuras de datos” de una forma ciertamente genérica: los nuevos algoritmos funcionarán con todas las estructuras de datos (contenedores) existentes, a la vez que sobre las nuevas estructuras de datos se podrán aplicar todos los algoritmos existentes. La STL viene, pues, a cubrir un hueco mal tapado hasta ahora por macros y clases no-estandarizadas, propias o de bibliotecas comerciales, usualmente poco efectivas, con un uso inadecuado de la herencia, con escaso o nulo chequeo de tipos, tan sustancial a C++.

En los páragrafos siguientes se expondrá, trufado con varios ejemplos (validados con VisualAge C++ para OS/2 y STL<ToolKit>), un acercamiento a la STL que no se pretende exhaustivo (toda vez que la sola descripción completa de las clases y algoritmos involucrados supera con mucho el ámbito de un artículo, ademas de existir un excelente manual de dominio público en que tales se detallan), sino más bien comprehensivo e iniciático. No se detallará, tampoco, la sintaxis y uso de las plantillas en C++. En definitiva mi intención es transmitir al lector el “espíritu” de la STL y la animosidad suficiente para que pueda usarla con efectividad, esperando, entre otras cosas, no vuelva a usar otra clase “vector” que la provista por esta esta biblioteca [1]. A ello.

ESTRUCTURA DE LA BIBLIOTECA

La STL está construida sobre cinco componentes:

aunque la relación fundamental entre componentes podría establecerse así:

Esto es, el núcleo de la STL son los algoritmos, que utilizan iteradores para acceder a contenedores. Como bien explican Stepanov y Lee, si quisiéramos codificar ‘c’ contenedores para ‘t’ tipos de datos accesibles mediante ‘a’ algoritmos, deberíamos contemplar ‘c*t*a’ combinaciones. Debido a la parametrización de tipos que procuran las plantillas, la STL sólo necesitaría ‘c*a’ combinaciones, que finalmente se reducen a ‘a+c’ por la reutilización de los algoritmos en diferentes contenedores.

Adicionalmente los componentes de la STL son al menos tan eficientes como los codificados a-mano (debido al uso del “inlining” y el prácticamente nulo uso de la derivación); proveen un fuerte chequeo de tipos (mediante el uso de plantillas); sus iteradores son generalizaciones de los punteros (pudiendo usarse donde tales aparecen, singularmente en los arrays de C); y permiten el uso, sobre todo en algoritmos, de funciones encapsuladas en objetos (también como el uso de las típicas funciones C/C++).

CONTENEDORES

En la STL se dan las siguientes categorías de contenedores, que en definitiva son “objetos que contienen otros objetos”:

que a su vez encierran las siguientes colecciones concretas, todas ellas codificadas en C++ mediante plantillas y con las subdisiviones que se indican:

Todas las colecciones de la STL tienen definido un interfaz mínimo, compuesto por las siguientes funciones públicas (se usará el contenedor “ list ” para los prototipos):

STL provee otras funciones de comparación (C) que se derivan (en sentido figurado) de los operadores == y < : <= , >= , > y != . En realidad STL provee tales operadores adicionales para cualquier objeto, supuesta la existencia de los dos primeros.

Pero veamos un ejemplo de uso de los contenedores STL:

class Politico{ /* protocolo */ };

Politico felipe, joseMaria, julio; // material de relleno

// definimos una lista doblemente-enlazada de Politicos

list<Politico> camarilla;

camarilla.push_back( felipe ); // inserta al final

camarilla.push_front( joseMaria ); // inserta al principio

// crea un iterador (que se verá más adelante) del tipo adecuado

// y lo inicializa apuntando a la primera posición de la lista

list<Politico>::iterator iterador = camarilla.begin();

// inserta un nuevo politico en la segunda posición de la lista

camarilla.insert( ++iterador, julio );

// le da la vuelta a la lista (‘julio’ sigue en medio)

camarilla.reverse();

camarilla.size(); // el tamaño actual de la lista: ‘3’

Los adaptadores son, en esencia, plantillas que procuran un interfaz especial para los otros tipos de contenedores. Así cualquier contenedor que soporte las operaciones de push_back y pop_back (como vector , list y queue ) puede ser usado para instanciar “ stack ”. Si se añade la operación front , entonces se podrá instanciar una “ priority_queue ”. Por fin “ queue ” podrá instanciarse con contenedores que soporten front , back , push_back y pop_front . Como el lector fácilmente habrá adivinado, los adaptadores “adaptan” o “adecúan” un determinado contenedor para que adopte un nuevo comportamiento, restringiendo ciertas características y cambiando otras.

“Bien, bien -exclamará el impaciente lector- Todo esto está muy bien, pero yo ya uso los contenedores de la biblioteca de clases X (o de una propia) que me van estupendamente”. ¡Estupendo! Pero el énfasis de la STL no está en los contenedores, sino en los algoritmos (que veremos poco después). De cualquier manera la genericidad que otorgan las plantillas es difícilmente superable por una biblioteca comercial, y la efectividad de los contenedores de la STL es, por otro lado, virtualmente inmejorable. Pero de poco sirve una mera estructura sin las herramientas que permitan accederla, revisar y modificar tanto su propia configuración como los ítems que contenga. Y aquí aparecen los iteradores.

ITERADORES

Según Andrew Koenig, “un iterador es algo que permite un conjunto de operaciones en una estructura de datos sin decir nada sobre la naturaleza de tal estructura”. Esta definición resulta especialmente relevante dentro del entorno que proporciona la STL pues ésta, centrada en los algoritmos, se encuentra con la dificultad de aplicar éstos directamente en los contenedores o estructuras genéricas de datos: algunos algoritmos funcionan con ciertas estructuras; otros no. Con la introducción de los iteradores se genera un nuevo nivel de indirección que permite, en su calidad de mediador, el perfecto entendimiento entre contenedores y algoritmos. Los iteradores, así, saben poco de algoritmos o de contenedores, de forma que son grandemente independientes de ambos. De esta manera los algoritmos se expresarán en términos de iteradores, de manera que las estructuras de datos accedidas, en otro nivel, por los iteradores, serán independientes de los primeros. De hecho esto es precisamente lo que diferencia a la STL de otras bibliotecas de clases.

Pero, ¿son en realidad los iteradores totalmente independientes de las colecciones que acceden? O sea, ¿cualquier iterador funciona en cualquier contenedor? Humm, parece que no, pues si, en el sentido práctico que nos ocupa, un iterador es un objeto que permite recorrer los elementos de una colección, recorriéndola (o “atravesándola”) con distintas estrategias, para cada estrategia quizás haya que procurar un iterador distinto. Ciertamente los iteradores de la STL funcionan, en general, tanto en los contenedores STL, como en los arrays de C o en los “streams” de C++, pero esto no significa que un iterador (un tipo de iterador) concreto funcione a la vez en todos. Nos hacen falta, pues, varios tipos de iteradores. Veámoslos:

• InputIterator (iterador de entrada/lectura): lee un solo item cada vez, en una única dirección, y su desreferenciación ( *iterator ) sólo podrá ser usada a la derecha de una asignación: esto es, la desreferenciación devuelve un elemento constante. Un puntero de C operando sobre un array predefinido es un iterador de lectura (veremos que también es de escritura, pero las dos condiciones incluyen la establecida). Así, por ejemplo, si consideramos el algoritmo “ max_element ”, con signatura:

template<class InputIterator>

InputIterator max_element(

// iterador en el primer ítem del rango elegido

InputIterator primero_,

// iterador tras el último ítem del rango elegido

InputIterator ultimo_ )

y cuya funcionalidad es devolver un iterador apuntando al mayor ítem dentro del rango [primero, ultimo) , para lo que usa el operador < , tenemos que, dado que usa iteradores de lectura, podremos usarlo con arrays y punteros:

int cabala[] = { 666, 17, 7 };

cout << *max_element( cabala + 1, cabala + 2 ) // ‘17’

// la desreferenciación aplicada al InputIterator que

// devuelve el algoritmo procura el ítem deseado (sólo lectura)

pero también con contenedores STL:

vector<int> monroe; // vector cinematográfico

// inserta elementos (int) al final del vector

monroe.push_back( 90 );

monroe.push_back( 60 );

monroe.push_back( 90 );

cout << *max_element( ++monroe.begin(), monroe.end() ); // ‘90’

Repare el lector que la aplicación de las funciones miembros “begin” y “end” al vector devuelve sendos iteradores, que pueden ser directamente usados en el algoritmo. La aplicación, por otro lado, del operador de pre-incremento origina que el iterador avance una posición desde el principio, posicionándose en el ítem con valor ‘60’, de manera que el algoritmo devuelve un iterador apuntando al tercer elemento con valor ‘90’ del vector, convenientemente desreferenciado. Dejamos al lector suponer cuál sería el resultado si se hubiera tomado como rango el vector entero.

• OutputIterator (Iterador de salida/escritura): Un iterador de escritura es como un iterador de lectura, con la particularidad que su desreferenciación ( *iterator ) sólo podrá ser usada a la izquierda de una asignación. O sea el iterador de lectura sólo lee ítems, y el de escritura sólo los escribe. Veamos un ejemplo de uso con el algoritmo “fill_n”, con signatura:

template<class OutputIterator, class Size, class T>

void fill_n (

OutputIterator primero_, // apunta al primer ítem del rango

Size n_, // limita el rango: primero_ + n_

const T& valor_ ) // valor de relleno

y cuya funcionalidad es rellenar un contenedor asignando a cada ítem, desde el ítem apuntado por el iterador ‘primero’ hasta el lugar ‘ n ’, el valor “ valor_ ”:

vector<int> quiniela( 15 );

fill_n( quiniela.begin(), quiniela.size(), 1 );

// el iterador de escritura que devuelve la función “begin()”

// se utiliza para escribir el valor ‘1’ en el ítem apuntado,

// y quiniela queda como { 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 }

• ForwardIterator (Iterador de lectura-escritura): se denomina así al iterador que a la vez opera como de lectura y escritura, como por ejemplo en el algoritmo “ iter_swap ”, con signatura: 

template<class ForwardIterator1, class ForwardIterator2>

void iter_swap(

ForwardIterator1 a_,

ForwardIterator2 b_, )

y cuyo sentido es intercambiar los elementos apuntados por los iteradores (cada iterador lee el ítem al que apunta, pero también lo escribe):

int vector<Politico> listaElectoral;

// se rellena la lista

// y se procede a aplicar el principio

// de intercambiabilidad de los politicos

iter_swap( listaElectoral.begin() + 1,

listaElectoral.begin() + 4 );

// se ha cambiado el segundo por el quinto

• BidirectionalIterator (Iterador bidireccional): se trata de un iterador de lectura-escritura al que se puede aplicar el operador ‘--’; esto es, que puede iterar en dos sentidos. Como ejemplo podemos considerar el algoritmo “ copy_backward ”, con signatura:

template< class BidirectionalIterator1,

class BidirectionalIterator2>

BidirectionalIterator2 copy_backward (

BidirectionalIterator1 primero_, // inicio rango origen

BidirectionalIterator1 ultimo_, // ++final rango origen

BidirectionalIterator2 resultado_ ) // ++final rango destino

y cuyo propósito es la copia de los elementos comprendidos en el rango [primero_, ultimo) en otro rango cuyo final está indicado por el iterador ‘ resultado_ ’ (que apunta a la posición tras el último elemento del rango). O sea, para copiar se da la posición final del destino (como si se copiara “hacia atrás”), copiando mediante el ‘ operator= ’. Lo que se devuelve es otro iterador del mismo tipo que ‘ resultado_ ’ pero apuntando al primer elemento del nuevo rango:

vector<Politico> listaPartidoD;

vector<Politico> listaPartidoI;

// se rellenan ambas listas

copy_backward( ++listaPartidoD.begin(),

--listaPartidoD.end(),

--listaPartidoI.end() );

// ahora ambas listas son iguales menos el

// primer y último elemento: la sin par realidad.

• RandomAccessIterator (Iterador de acceso aleatorio): se trata de un iterador bidireccional que admite la adición y substracción de enteros, la computación de la distancia entre dos iteradores y la indexación. Si usamos el algoritmo “partial_sort”, con signatura:

template<class RandomAccessIterator>

void partial_sort (

RandomAccessIterator primero_,

RandomAccessIterator medio_,

RandomAccessIterator final_ )

y cuya funcionalidad es la de ordenar, usando operator<, los primeros n elementos en el rango [primero_, final) , donde n = medio_ - primero_ (operación permitida sólo en los iteradores de acceso aleatorio), dejando el resto del rango en orden indefinido:

int array[ 7 ] = { 6, 4, 2, 1, 5, 3, 7 };

partial_sort( array, array + 4, array + 7 );

// resultado: { 1, 2, 3, 4, 7, 5, 6 }

Como vemos, los punteros de C son, en realidad, iteradores de acceso aleatorio, como el lector ya había adivinado. De hecho los iteradores son generalizaciones de punteros, y su semántica es una generalización de la de aquéllos. Así Musser expresamente nota que “Cualquier tipo de puntero C++, T* , obedece todas las leyes de la categoría de iteradores de acceso aleatorio ”.

En resumen, si ‘i’ y ‘j’ son iteradores y ‘n’ un entero cualquiera, se cumple:

dándose la siguiente relación entre iteradores:

de forma que donde se espera un cierto iterador, puede aplicarse cualquier iterador a su derecha. Y, claro, aquí el lector podría exclamar: “¡Una jerarquía de herencia de iteradores!”. Pues no, irredento lector: nada de jerarquías: aunque parezca lo contrario, la clase del iterador bidirectional no “deriva” de la clase del iterador forward, como no lo hacen tampoco las demás. Andrew Koenig acertadamente afirma que habría que pensar en las relaciones entre iteradores como “herencia conceptual”, pues un iterador es una familia de tipos relacionados en razón de formas que no son directamente expresables en C++.

Además de los iteradores expuestos, la STL provee otros igualmente útiles: istream_iterator y ostream_iterator (que operan como cin y cout respecto de streams C++ de entrada y salida, respectivamente), reverse_bidirectional_iterator y reverse_iterator (que iteran hacia atrás), insert_iterator (inserta en la posición a que apunta), back_insert_iterator y front_insert_iterator (sólo insertan al final y al principio de un contenedor, respectivamente), etc.

¡Demasiados iteradores! -podría aquí perfectamente exclamar el lector: ¿Cómo saber qué iterador aplicar en cada contenedor o algoritmo? Bueno, respecto de los algoritmos sólo hay que mirar su signatura o prototipo; respecto de los contenedores, he aquí la tabla:

donde se explicita algo evidente: únicamente las “Colecciones de Primera Clase” (esto es, contenedores secuenciales y asociativos) pueden ser accedidas por iteradores. La ligazón entre contenedores, iteradores y algoritmos se produce así: la descripción de los contenedores incluye la categoría de los tipos de iteradores que proveen, mientras que los algoritmos genéricos incluyen (en su prototipo) la categoría de iteradores con que trabajan. Así, para evitarle al usuario la consulta o aprendizaje de tablas como la anterior, cada contenedor define una serie adecuada de typedef s, de forma que la notación contenedor<class T>::iterator enmascara los tipos:

Pero además se dan los siguiente útiles typedef s:

para iterar adecuadamente en colecciones “escribibles” o de “sólo-lectura”, hacia adelante o hacia atrás. De esta manera, podríamos trabajar con los iteradores de la siguiente guisa:

list<Politico> cuadrilla;

// aquí se rellena la lista, y seguidamente

// se define un iterador del tipo adecuado

// (que en este caso será bidireccional)

list<Politico>::const_iterator i = cuadrilla.begin();

// y ahora se utiliza el iterador

for ( i; i != cuadrilla.end(); i++ )

// supondremos que la clase Politico sobrecarga

// el operador de inserción (y esto no parece des-

// cabellado, pues los políticos lo sobrecargan todo).

cout << *i << “\n”; //imprime la lista

// Y ahora al revés

list<Politico>::const_reverse_iterator ri;

// y en lo siguiente aparecen dos nuevas funciones marcadas

// por una r (reverse) inicial: rbegin() devuelve un iterador

// posicionado en el ultimo ítem, mientras que rend() devuelve

// un iterador posicionado inmediatamente antes del primer ítem.

// Su uso es evidente para iteradores que operan al revés.

for ( ri = cuadrilla.rbegin(); ri != cuadrilla.rend(); ri++ )

cout << *i << “\n”;

dejando que los typedef s hagan el trabajo de elección del iterador correcto por nosotros. ¿No es sencillamente fantástico?

ALGORITMOS

He aquí el corazón de la STL: algoritmos reutilizables. Y es que a pesar de la importancia de los algoritmos que acompañan a la biblioteca, lo verdaderamente significativo se encuentra en el entorno-marco que procura protocolos exactos para la adición de otros muchos algoritmos, tal y como hemos visto al revisar los iteradores.

Los algoritmos en la STL hacen uso de iteradores y objetos-funciones (de entre ellos los “predicados”) para acceder a los elementos de los contenedores. De entre los numerosos algoritmos que vienen con la librería, y que el lector puede escudriñar en el completo manual, podemos mencionar:

Pero veamos un ejemplo de un algoritmo eminentemente práctico: “ for_each ”, que con signatura

template<class InputIterator, class Function>

Function for_each {

InputIterator primero_,

InputIterator ultimo_,

Function funcion_ }

tiene como propósito aplicar a cada elemento comprendido en el rango [primero_, ultimo_) la función determinada por funcion_ :

vector<Politico> listaNegra;

void detecta( const Politico& politico ) {

if ( politico.piensa() )

listNegra.pushBack( politico );

}

list<Politico> lista;

// se rellena convenientemente la lista

for_each( ++lista.begin(), lista.end(), detecta );

¿Qué es lo que aquí sucede? El algoritmo for_each aplica a cada elemento de la lista (a partir del segundo) la función ‘ detecta ’, que toma como argumento el elemento visitado en cada caso, y esta función discrimina a los políticos con ideas, que son insertados en una lista negra para un rápido direccionamiento al ostracismo. Pero en el ejemplo vemos también que una función se trata como un objeto. Y es exactamente eso.

¿FUNCIONES-OBJETO U OBJETOS-FUNCIONES?

Muchos de los algoritmos usan de funciones que son aplicadas a los elementos de los contenedores por medio de iteradores. Tales funciones pueden ser bien punteros a funciones normales de C/C++ o una generalización de éstas: funciones encapsuladas en objetos. Los objetos-funciones son instancias de clases con un comportamiento definido por sus funciones miembros públicas, pero cuya sintaxis simula la de las funciones C mediante la sobrecarga del operador (); pero además los objetos-funciones incorporan datos miembros y operan como el resto de los objetos: se crean, se modifican y se destruyen. En general los objetos-funciones, o simplemente funciones respecto de la STL, pueden dividirse en unarios o binarios, dependiendo si toman uno o dos argumentos, pero también, en función de su propósito, en

Pero veamos un ejemplo de cada uno, empezando por los predicados. Si consideramos el algoritmo “ find_if ” con prototipo:

template<class InputIterator, class Predicate>

InputIterator find_if (

InputIterator primero_,

InputIterator ultimo_,

Predicate predicado_ )

que devuelve un iterador apuntando al primer elemento del contenedor que cumple el predicado (esto es, la función de tipo Predicate aplicada a ese elemento devuelve “ true ”):

bool traeMalaSuerte( int numero ) {

return numero == 13;

}

vector<int> numeros;

numeros.push_back( 4 );

numeros.push_back( 13 );

numeros.push_back( 13 );

vector<int>::iterator i;

i = find_if( numeros.begin(), numeros.end(), traeMalaSuerte );

// i apunta al segundo elemento del vector

Veamos seguidamente cómo operan los comparadores. Si consideramos el algoritmo “ min ” con prototipo:

template<class T>

const T& min( const T& a_, const T& b_, Compare comparador_ );

cuya funcionalidad es la de comparar los elementos a_ y b_ usando la función determinada por comparador_, devolviendo el menor elemento:

bool comparaPoliticos(const Politico& uno, const Politico& otro) {

return ( uno.votos() < otro.votos() );

}

Politico julio, jordi; // y se inicializan debidamente después

cout << min( jordi, julio, comparaPoliticos ) << “\nl”;

Por último examinemos las funciones generales, para lo que trataremos con el algoritmo “count_if” con prototipo:

template<class InputIterator, class Predicate, class Size>

void count_if (

InputIterator primero_,

InputIterator ultimo_,

Predicate predicado_,

Size& n_ );

y que procura el número de ocurrencias del cumplimiento de un determinado predicado respecto de cada uno de los elementos de un contenedor. Como predicado usaremos el objeto-función logical_not, que devuelve “ true ” si el argumento que se le pasa es cero, definido así en la STL:

template<class T>

struct logical_not : unary_function<T, bool> {

// ...

bool operator()( const T& x_ ) const {

return !x_;

}

};

y que encaja perfectamente en el ejemplo siguiente:

vector numeros[ 8 ] = { 0, 1, 0, 0, 1, 1, 1, 1 };

int n = 0;

count_if( numeros, numeros + 2, logical_not<int>(), n );

cout << n; // imprime ‘2’

Como vemos los objetos-funciones necesitan ser parametrizados y esta operación puede ser prolija: para facilitar esta labor aparecen los adaptadores de funciones. Así, por ejemplo, los “negadores” not1 y not2 toman como argumento predicados unarios y binarios y devuelven sus complementos. Pero no abundaremos más en adaptadores, cuyo estudio se deja al ávido lector.

DE LOS PELIGROS DE LA EXTENSIBILIDAD

Examinemos, por ejemplo, el algoritmo “ count() ”, que cuenta el número de ítems en un contenedor que satisfagan un determinado valor. Su prototipo es:

template<class InputIterator, class T, class Size>

void count

{

InputIterator first_, // iterador en el primer ítem

InputIterator last_, // iterador tras el último ítem

const T& value_, // el valor a comparar

Size& n_ // el contador a incrementar por cada ocurrencia

}

O sea, este algoritmo recorre una coleccion o contenedor desde el primer elemento hasta pasado el último, y compara cada ítem encontrado con “ value ” aplicando el operador ==. Si la comparación devuelve “ true ” entonces se sumará uno a “ n ”. Pero el lector, siempre atento, notará que el algoritmo no inicializa “ n ” a cero, y ni siquiera devuelve el número de ocurrencias, que parece lo más intuitivo, sino “ void ”. Pero tal es natural, pues la reusabilidad de un algoritmo se sustenta en no fijar presunciones que lesionen su genericidad: de esta manera podemos pasar por referencia a “ count() ” una variable con un valor anterior para que sea modificada con las ocurrencias buscadas (caso que se da, por ejemplo, en la concatenación de dos o más búsquedas sobre la misma o distinta colección). Se deja, así, al usuario de la STL que especifique expresamente su intención:

// definimos un array (arreglo?!) de ocho elementos

int vector[] = { 1, 2, 2, 3, 3, 3, 2, 2 };

int contador = 0;

count( vector, vector + 8, 2, contador );

cout << contador; // devuelve ‘4’ (ocurrencias del 2)

count( vector, vector + 8, 1, contador );

cout << contador; // ‘5’ (ocurrencias del 2 ó del 1)

Bien, bien -reconoce aquí el lector-: de acuerdo con la genericidad pero ¿y si yo quiero algo más sencillo? O sea, ¿No resulta peligrosamente tendente al error tanta genericidad? Por otra parte, si ya conocemos el contenedor sobre el que se aplica el algoritmo, ¿por qué repetirlo en los dos primeros argumentos? ¿Y si se me olvida inicializar el contador? ¿No sería más adecuada una versión “simplificada” de tales algoritmos, quizás por derivación de clases? Bueno, el lector ha puesto el dedo en la llaga, como siempre. Pero ¿es la llaga correcta? Hay que pensar que esto mismo le achacaban los pascalistas al C: “Demasiada libertad es peligrosa” (cualquier remembranza política es deliberada). Veamos los peligros de dejar “demasiada responsabilidad” en manos del usuario:

vector<Politico> listaMunicipal;

vector<Politico> listaAutonomica;

// seguidamente se “llenan” los vectores con criterios

// que escapan a los propositos de este artículo y por

// lo común a la lógica y la prudencia.

Politico discolo;

// se inicializa debidamente del objeto díscolo (o sea,

// se ponen algunas ideas en él).

int contador; // ¡oops! No se ha inicializado.

// seguidamente querremos contar cuántos políticos

// díscolos hay en una determinada lista.

count( listaMunicipal.begin(),

// seguidamente se cambia de vector (¡Horror!)

listaAutonomica.end(),

discolo,

contador ); // error: sin inicializar

// ¿El resultado? ¡Impredecible!

Visto lo anterior parece que para la mayoría de los casos un algoritmo como el siguiente sería mucho más legible y seguro:

int politicosDiscolos = listaMunicipal.count( discolo );

a lo que se podría llegar derivando de la clase “ vector ” en la STL una nueva clase que incorporara como función miembro una función “ count() ” que, a su vez, usara del algoritmo “ count() ”. Algo así como:

template<class T> class vectorEspacial : public vector<T> {

public:

int count( const T& valor_ ) const {

int n = 0;

count( begin(), end(), valor_, n );

return n;

}

// sigue resto protocolo clase

};

De esta manera las listas anteriores deberían ser instanciadas como objetos de nuestro vector personalizado:

vectorEspecial<Politico> listaMunicipal;

vectorEspecial<Politico> listaAutonomica;

Y ahora sí se podría utilizar la función miembro, como antes se ha visto. De hecho este es el enfoque que han adoptado la mayoría de implementaciones comerciales de la STL, con el objetivo de facilitar el uso de la biblioteca a los usuarios. Pero este enfoque tiene muchos puntos negros. Veámoslos:

• Para cada algoritmo deberá añadirse una función miembro a nuestra clase. Así, y aparte de la duplicación de clases que la derivación supone (para cada clase en la STL habrá de crearse una nueva clase derivada con funciones miembros reflejando cada algoritmo), dada la naturaleza de la STL, que invita a añadir nuevos algoritmos, el interfaz de las clases derivadas debería ser cambiado con relativa frecuencia.
• La eficacia inherente a la STL se ve perjudicada por la introducción de jerarquías de herencia y destructores virtuales.
• La facilidad por derivación enfatiza el uso de clases “no-normalizadas”, de manera que el código generado no se acoje a normas de estandarización y por tanto plantea problemas para su extensión y acoplamiento a distintos entornos.

Un enfoque sustancialmente distinto es el que adopta STL<ToolKit>, de ObjectSpace Inc. Para facilitar el uso de los algoritmos de la STL, éstos han añadido unos cuantos llamados “algoritmos de ayuda”, que anteceden los identificadores estándar de la STL con el prefijo “ os_ ”, de forma que así se podría codificar:

vector<Politico> listaMunicipal; // vector estándar STL

int PoliticosDiscolos = os_count( listaMunicipal, discolo );

donde os_count sería codificada como:

template< class Contenedor, class T > inline

int os_count( const Contenedor& c, const T& valor ) {

int n = 0;

count( c.begin(), c.end(), valor, n );

return n;

}

Personalmente me parece una solución que, además de respetar el espíritu de la STL, resulta tan eficiente como la original (por su implementación “inline”), pero más fácil de usar para la mayoría de situaciones, aparte de no incurrir en ninguna de las anteriores desventajas (el mismo algoritmo de ayuda funciona, por ejemplo, para todos los contenedores de la STL).

LEVES CRÍTICAS

Si la STL es tan endiabladamente buena, ¿qué impide su adopción generalizada? ¡Nada! Bueno, sí, quizás una cierta candidez cultural, semejante a la de aquellos ciudadanos que no comen marisco en público por temor -mayormente fundado- a no saber manejarse con los cubiertos. En realidad la propia sintaxis del lenguaje es mucho más prolija y compleja que la estructuración en que se basa la STL, de forma que cualquiera que use C++ debiera usar STL o, más aún, la Biblioteca Estándar del lenguaje que incluye, en ella diluida y sin forma explícita, a la STL. ¡Ah, pero biblioteca no es bibliotenaje! Esto es, como titularía Pitigrilli, “El pollo no se come con la mano”: hay que estudiar y entender la STL antes de usarla, así como apreciar los leves inconvenientes derivados de su uso, que en la actualidad se reducen a dos: la dificultad de depuración del código erróneo (debida no tanto a la estructura de la biblioteca como a sus actuales implementaciones) y el aumento del tamaño de los ejecutables (que Cargill cifra en un 25%). Hay que afinar la balanza, señores, pero sinceramente no creo que tales dificultades afecten al grueso de los programadores en C++.

APRENDIZAJE Y DOCUMENTACIÓN

La implementación de STL de Hewlett Packard, que con una decisión encomiable liberó todas las licencias afectas a la biblioteca convirtiendo la STL y el trabajo de muchos años en “freeware”, fue distribuida por RPP en un disquete, pero también puede ser conseguida, junto con el manual de Stepanov y Lee en postscript, mediante ftp anónimo bien en ftp://butler.hpl.hp.com/stl/ bien en ftp://ftp.cs.rpi.edu/pub/stl/ , pero también en distintos foros electrónicos (como el de Microsoft Spain en CI$). En el World-Wide Web habría que echarle un vistazo a la página (home page) que mantiene David R. Musser, del Instituto Politécnico Rensselaer, en http://www.cs.rpi.edu/~musser/stl , con documentación on-line y varios enlaces. En general los enlaces de OOA/D/P pueden ser accedidos a través de “ La Página Orientada-a-Objetos” (The Object-Oriented Page: The OOPage) que yo mismo edito para Galaxy en el Web[2] ( http://galaxy.einet.net/galaxy/Engineering-and-Technology/Computer-Technology/Object-Oriented-Systems/ricardo-devis/oo.html), o también a través de mis propias páginas personales en The Well (http://www.well.com/user/ritchie).

En cuanto al aprendizaje y uso, en repetidas ocasiones he mencionado el manual que acompaña a la STL. Naturalmente este manual es perfecto si la perfección estilística se entiende a la manera de Borges: esto es, eliminando adjetivos y vocablos en un proceso iterativo que genera un documento denso y completo, pero que hay que releer varias veces, y donde lo esencial ni siquiera se separa de lo accesorio, en aras de la comletitud formal, claro. Bien: el manual de Stepanov y Lee es perfecto (perfectamente técnico) y un cierto ejemplo sobre cómo debe componerse una buena documentación. Sin embargo, para iniciarse en la STL (o para el gran público, que dicen los legalistas de C++) quizás sea mejor atender a otros textos (y es que Voltaire acuñó una frase omnipresente en informática). Pero, ¿qué textos? Pues los de las implementaciones comerciales de la STL, que son bastante buenos. ¡Un momento, un momento! ¿Implementaciones comerciales? ¡Pues claro! La STL hace un uso extensivo e intensivo de las plantillas y, por ende, carece de un soporte pre-construido que cubra la mayoría de los compiladores del mercado, características que proporcionan los vendedores de STL, que además incorporan diversas golosinas, ciertamente prácticas, que aumentan la facilidad y funcionalidad de la STL.

Las implementaciones comerciales actuales arrostran un precio usualmente no superior a los $200,00 y básicamente (existen algunas más) se deben a Modena Software Inc. (Stl++), con soporte para tablas hash, y ObjectSpace Inc. (Stl<ToolKit>), con soporte para la mayoría de los compiladores C++ actuales, aunque Rogue Wave ha anunciado también la inclusión de la STL en su conocida biblioteca de clases Tools.h++. Restringiéndonos a los dos primeras, ambas con buenos manuales y varios añadidos, yo recomendaría la segunda: STL<ToolKit>, que provee un manual de 421 páginas perfectamente pedagógico, con más de 250 ejemplos de uso y una distribución de la información sencillamente perfecta (tanto es así que parece que en breve se publicará el manual como libro en Prentice Hall). Además ObjectSpace, accesible en el Web por http://www.objectspace.com provee extensiones “multi-thread”, multitud de “algoritmos de ayuda” y soporte para asignadores dinámicos de memoria.

REFERENCIAS DIRECTAS

• Cargill, T. STL Caveats, C++ REPORT, 7(6), julio-agosto 1995.
• Barreiro, J.-Fraley R. & Musser D.R. Hash Tables for the Standard Template Library, X3J16/94-0218, WG21/N0605, enero 95.
• Devis Botella, R. Contenedores y Plantillas en C++, RPP, febrero 1995.
• Koenig, A. The ideas behind STL, X3J16/94-0134, WG21/N0521, 1994.
• Musser D.R. The Standard Template Library Home Page, WWW 26/07/95.
• ObjectSpace Inc. STL<ToolKit> User Guide, mayo 1995.
• Stepanov, A. & Lee, M. The Standard Template Library, X3J16/94-0140, WG21/N0527, julio 1994.
• Stroustrup, B. Making a vector fit for a standard, C++ REPORT, 6(8), octubre 1994.
• Vilot, M. An Introduction to the Standard Template Library, C++ REPORT, 6(8), octubre 1994.

[1] Mucha gente piensa, como Prémontal, que las bibliotecas son como las farmacias: muchos venenos y pocos remedios. Así que prefieren las soluciones caseras a-mano. El mercado mismo evidencia su error.

[2] ¡Ah, lo siento! Para mí es “el Web” y no “ la Web”. Y es que pese a la traducción de “Telaraña a lo ancho del mundo” (que a mí me resuena a un cierto Capitán Tan), los barbarismos “WWW”, “World-Wide Web”, “Web” ó “W3” me resultan terminantemente masculinos. Claro que una solución “políticamente correcta” sería la de “el/ la Web”, tan común hoy en día en los textos norteamericanos. Pero, vaya, tras leer la versión “políticamente correcta” de “Los Tres Cerditos” creo que me batiría en duelo por reivindicar el sano derecho a la incorrectitud individual.