Disponible la versión 6 de OrganiZATOR
Descubre un nuevo concepto en el manejo de la información.
La mejor ayuda para sobrevivir en la moderna jungla de datos la tienes aquí.

Curso C++

[Home]  [Inicio]  [Índice]


1.4.4b  Librerías: generalidades


Nota:  tenga en cuenta que este capítulo no trata de características que puedan considerarse estándar del lenguaje C++, sino de peculiaridades (aunque muy extendidas) de la construcción de aplicaciones.  Tenga en cuenta también que en informática, el concepto "Librería" es muy general, y no está asociado a ningún lenguaje concreto (aunque C y C++ las utilizan ampliamente). De hecho, es posible y frecuente, utilizar en un lenguaje librerías que han sido escritas en otro. Por ejemplo, buena parte de las librerías de C++Builder, la denominadas VCL "Visual Component Library", han sido desarrolladas en Pascal ( 4.11.8b).

§1  Sinopsis

Al tratar de la construcción de un programa ( 1.4) señalamos que en ocasiones no se desea construir un ejecutable, al menos no en el sentido tradicional del término, sino una librería, y que estas librerías son trozos de código que contienen alguna funcionalidad pre-construida que puede ser utilizada por un ejecutable. Por supuesto, las librerías contienen en su interior variables y funciones. Si como suponemos son librerías C++, lo más probable es que estas variables y funciones estén encapsuladas en forma de clases ( 4.11).  Observe que la idea central de librería es precisamente la de ser un módulo de software preconstruido -generalmente por terderos- para cuya utilización no es necesario conocer los detalles íntimos de su funcionamiento, sino su interfaz. Es decir, que respuestas nos puede dar y cómo hay que preguntar -a la librería- para obtenerlas.

En general, el término librería se utiliza para referirse a un conjunto de módulos objeto .obj / .o (resultados de compilación) agrupados en un solo fichero que suele tener las extensiones .lib, .bpl [6] .a, .dll, etc. Estos ficheros permiten tratar las colecciones de módulos como una sola unidad, y representan una forma muy conveniente para el manejo y desarrollo de aplicaciones grandes, además de ser un concepto muy fértil para la industria del software, ya que permiten la existencia de las librerías de los propios compiladores ( 5) y de un mercado de utilidades y componentes adicionales. Son las denominadas librerías 3pp (de terceras partes), en referencia a que no son incluidas de forma estándar con los compiladores ni creadas por el programador de la aplicación.

En este sentido el software se parece a cualquier otro mercado de componentes. Además de las librerías más o menos extensas que acompañan a los compiladores, pueden adquirirse otras, que permiten añadir a nuestros programas las funcionalidades más diversas sin necesidad de ser un experto en cada área de la programación y sin necesidad de que tengamos que estar reinventando la rueda constantemente.  Si quiere una opinión autorizada -en inglés- sobre la filosofía de uso e importancia de las librerías en C++, puede consultar este documento del Sr. Stroustrup:  Abstraction, libraries, and efficiency in C++

§2  Tipos

En lo que respecta al lenguaje C++, existen dos tipos fundamentales de librerías: estáticas y dinámicas, que aunque comparten el mismo nombre genérico "librería", utilizan mecanismos distintos para proporcionar su funcionalidad al ejecutable.

En ambos casos es costumbre, que junto a las librerías propiamente dichas (ficheros .lib, .a, .dll etc), se incluya un fichero .h denominado "de cabecera" ( 4.4.1), porque es tradición utilizar las primeras líneas del programa para poner las directivas #include ( 4.9.10g) que los incluirán en el fuente durante la fase de preproceso ( 1.4).  Este fichero contiene las declaraciones de las entidades contenidas en la librería, así como las macros y constantes predefinidas utilizadas en ella, de forma que el programador solo tiene que incluir el correspondiente fichero .h en su aplicación para poder utilizar los recursos de la librería en cuestión (recuerde que en C/C++ es imprescindible incluir la declaración de cualquier función o clase antes de su utilización 4.1.2). Este sistema tiene la ventaja adicional de que proporciona al usuario la información mínima para su uso.  Es decir, la "interfaz" de las funciones o clases que utilizará.  En el caso de funciones esto se concreta en el prototipo ( 4.4.1); en el caso de clases, en la especificación de sus métodos y propiedades públicas.

§2.1  Librerías estáticas

Denominadas también librerías-objeto, son colecciones de ficheros objeto (compilados) agrupados en un solo fichero de extensión .lib, .a, etc. junto con uno o varios ficheros de cabecera (generalmente .h).

Nota: una posición extrema la constituyen aquellas librerías en las que toda la funcionalidad se ha incluido en el fichero de cabecera .h, en cuyo caso no existen los módulos compilados .lib, .a, etc. Es el caso de la Librería Estándar de Plantillas STL ( 5.1) que está compuesta casi exclusivamente por ficheros de cabecera.  No obstante, lo anterior representa un caso extremo que suele ser evitado, ya que por lo general, los autores incluyen en los ficheros de cabecera la información mínima indispensable para utilizar la librería (la interfaz), incluyendo la operatoria en forma de ficheros compilados.  La razón no suele ser otra que proteger la propiedad intelectual (el "know how").

Durante la construcción de la aplicación, el preprocesador incluye en los fuentes los ficheros de cabecera. Posteriormente, durante la fase de enlazado, el linker incluye en el ejecutable los módulos correspondientes a las funciones y clases de librería que hayan sido utilizadas en el programa, de forma que el conjunto entra a formar parte del ejecutable. De ahí su nombre: Librerías enlazadas estáticamente [1].

Dejando aparte consideraciones de comodidad y rapidez, el  resultado de utilizar una de tales librerías no se diferencia en nada al que puede obtenerse escribiendo en al fuente las funciones o clases correspondientes y compilándolas como un módulo más de nuestra aplicación.

Nota:  genralmente los compiladores disponen de herramientas específicas para la creación de librerías estáticas. Por ejemplo, la del compilador Borland C++ es el ejecutable TLIB.EXE ( 1.4.0w1); las de GNU se denominan ar y ranlib. Como tendremos ocasión de ver en los ejemplos, también pueden crearse mediante opciones específicas en la orden de compilación.

§2.1.1  Diccionario

Junto con los módulos .obj que las componen, las librerías estáticas incluyen una especie de índice o diccionario con información sobre su contenido. Este índice contiene los nombres de los recursos públicos de los distintos módulos (que pueden ser accedidos desde el exterior) y su dirección. Estos nombres deben ser distintos para evitar ambigüedades durante el enlazado, y sirven para incrementar la velocidad de enlazado cuando el "Linker" debe incluir alguno en un ejecutable.

Nota:  cuando se crea una librería estática a partir de uno o varios ficheros relocalizables (objetos), el proceso de incluir esta tabla o diccionario de símbolos puede ejecutarse en un solo paso o en dos, aunque siempre en el momento de crear la librería.  Por ejemplo, tlib de Boland crea la librería y la tabla en un solo proceso.  En cambio, ar de GNU puede crear la librería y posteriormente añadir la tabla (esto último puede también hacerse con ranlib).  Cuando se añade un nuevo módulo a una librería existente, la misma herramienta que añade el contenido, se encarga de actualizar el índice. 

 §2.2  Librerías dinámicas

Otra forma de añadir funcionalidad a un ejecutable son las denominadas librerías de enlazado dinámico (repasar en 1.4.4 el significado de "enlazado dinámico"), generalmente conocidas como DLLs, acrónimo de su nombre en inglés ("Dynamic Linked Library"). Estas librerías se utilizan mucho en la programación para el SO Windows. Este Sistema contiene un gran número de tales librerías de terminación .DLL, aunque en realidad pueden tener cualquier otra terminación .EXE, .FON, .BPI, .DRV etc. Cualquiera que sea su terminación, de forma genérica nos referiremos a ellas como DLLs, nombre por el que son más conocidas.

Nota:  la programación tradicional de aplicaciones Windows utilizando la API del Sistema ( 1.7.1) es en realidad una sucesión de invocación a funciones contenidas en librerías de este tipo.  En realidad este Sistema Operativo está constituido por un conjunto de DLLs; la mayoría de los ficheros de disco asociados con el Sistema son de este tipo, y se ha llegado a afirmar que escribir una DLL es escribir una extensión del propio Windows ( PW2E Petzold p.878).

§3  Diferencias:  librería Estática "versus" Dinámica

Las diferencias más relevantes de las librerías dinámicas respecto a las estáticas son fundamentalmente dos:

  • Las librerías estáticas quedan incluidas en el ejecutable, mientras las dinámicas son ficheros externos, con lo que el tamaño de la aplicación (nuestro ejecutable) es mayor en el primer caso que en el segundo. Esto puede ser de capital importancia en aplicaciones muy grandes, ya que el ejecutable debe ser cargado en memoria de una sola vez [3].

  • Las librerías dinámicas son ficheros independientes que pueden ser invocados desde cualquier ejecutable, de modo que su funcionalidad puede ser compartida por varios ejecutables. Esto significa que solo se necesita una copia de cada fichero de librería (DLL) en el Sistema. Esta característica constituye la razón principal de su utilización, y es también origen de algunos inconvenientes, principalmente en sistemas como Windows en los que existen centenares de ellas.


Como consecuencia de las diferencias citadas se derivan otras. Por ejemplo:

  • Si se realizan modificaciones en los módulos de una librería estática, es necesario recompilar todos los ejecutables que la utilizan, mientras que esto no es necesario en el caso de una librería dinámica, siempre que su interfaz se mantenga.

  • Como consecuencia de lo anterior, generalmente es más difícil la depuración y mantenimiento de aplicaciones que utilizan librerías dinámicas que las estáticas, ya que en el primer caso, es necesario controlar qué versiones de los ejecutables (.EXE) son compatibles con qué versiones de las DLLs y de estas entre sí, de forma que el usuario no utilice un versiones incompatibles de los ficheros que componen la aplicación.

  • Durante la ejecución de un ejecutable, las librerías estáticas que hubiesen intervenido en su construcción no necesitan estar presentes, en cambio las dinámicas deben estar en el mismo directorio o en el camino de búsqueda "Path" [7].

  • Las librerías estáticas solo se utilizan en la fase de construcción del ejecutable. Las dinámicas se utilizan durante la ejecución.

  • Los ejecutables que utilizan librería estáticas solo incorporan los módulos de aquellas que necesitan para resolver sus símbolos externos.  Por contra, las librerías dinámicas deben ser cargadas en su totalidad aunque no solo se utilice una parte de su funcionalidad (no son divisibles).

  • Las librerías estáticas, que entran a formar parte indivisible del ejecutable, son cargadas con el proceso de carga de este.  Las librerías dinámicas no necesariamente tienen que cargarse con la carga inicial (aunque pueden serlo). De hecho, una librería dinámica puede ser cargada bajo demanda en el momento en que se necesita su funcionalidad, e incluso puede ser descargada cuando no resulta necesaria.

  • El mecanismo de enlazado estático depende del compilador.  El de enlazado dinámico depende del SO, de forma que manteniendo ciertas precauciones, las DLLs construidas con un lenguaje y un compilador pueden ser utilizadas por cualquier aplicación.

§4  Utilizar Librerías

Desde la óptica del programador C++, el manejo de librerías comprende dos aspectos totalmente diferenciados: su utilización y quizás la construcción de alguna de ellas si nuestras aplicaciones son medianamente grandes.

En cuanto al primer punto, es seguro que cualquier aplicación por pequeña que sea, utilice algunas de la Librería Estándar ( 5). Por ejemplo, cada vez que en su código aparece una sentencia del tipo

cout << "Hola mundo" << endl;

está utilizando una librería estática, y cada vez que en la programación de una aplicación Windows utiliza un mensaje del tipo

MessageBox(NULL, "Hola mundo!", "Mi primer programa", MB_OK);

está usando una librería dinámica.  En cuanto a su construcción, si se dedica a esto de programar en C++, antes o después pondrá manos a la obra. Por cierto: existen empresas de software cuya principal actividad es precisamente fabricar y vender librerías (ya hemos indicado que el mercado de las 3pp es todo un "mundillo" dentro de la informática).

Cualquiera que sea el caso, tanto la utilización como la construcción, son diferentes según se trate de librerías estáticas o dinámicas. En las páginas que siguen se describen en detalle ambas situaciones. Empezaremos por una descripción general de su funcionamiento, para continuar con la descripción de los pasos necesarios para construirlas.  A continuación exponemos los detalles de su utilización, incluyendo un ejemplo de construcción de un ejecutable que utiliza los recursos de una librería.

  Inicio.


[1]   Recordemos que en C++, uno de los significados del término "estático" es algo que ha sido resuelto en tiempo de compilación  ( 1.4.4).

[3]  Existen utilidades que permiten compactar ("Squeeze") un ejecutable disminuyendo su tamaño como fichero, lo que puede ser de utilidad a la hora de transportarlo (por redes por ejemplo). Pero incluso en estos casos, después de cargados en memoria deben ser "expandidos" a su tamaño normal y reacomodados en memoria según un patrón definido por el SO.

[6]  BPI; acrónimo de Borland Package Import Library. Un tipo especial de librería dinámica del citado compilador, que utiliza enlazado estático con el ejecutable que las usa.

[7]  En el caso del compilador BC++, durante la construcción de un programa o librería, este "path" puede ser controlado mediante el comando de compilación -L o de enlazado /L. Más tarde durante la ejecución (runtime) el "path" depende de las variables de entorno del sistema.

En los programas para Windows caben tres opciones: poner las librerías específicas en el mismo directorio que el ejecutable (o un subdirectorio del anterior); en nuestra opinión esto sería lo recomendado. Otra opción es ponerlas junto con el resto de librerías del sistema (Windows\System) o en un directorio particular cualquiera (no es aconsejable).