Archivo de cabecera

En la mayoría de lenguajes de programación modernos, los programadores pueden dividir los programas en componentes de menor tamaño (como pueden ser clases y subrutinas) y distribuir esos componentes entre muchas unidades por traducir (típicamente en forma de archivos), que el sistema puede compilar de forma autónoma. Si una subrutina se tiene que usar al margen de la unidad por traducir donde ha sido definida, se tiene que introducir el concepto de declaración directa o prototipos de funciones. Por ejemplo, una función definida así en un archivo fuente:

 int add(int a, int b) 
 {
     return a + b;
 }

puede declararse (con un prototipo de función) y ser referida desde un segundo archivo fuente como sigue:

 int add(int, int);
 
 int triple(int x)
 {
     return add(x, add(x, x));
 }

Sin embargo en esta simple ilustración se requiere que el programador mantenga la declaración de la función de add en dos sitios  — en el archivo que contiene su implementación y en el archivo que usa la funcionalidad. Si la definición de la función llega a alterarse, entonces el programador debe actualizar todos los prototipos repartidos a lo largo del programa. Esto es necesario porque la implementación de ambos, C y C++ han de diagnosticar todas las violaciones de lo que en C++ se llama "one definition rule" (ODR), al español "regla de una única definición". De hecho, la mayoría de ellos se sirven de un enlazador para realizar esta labor. El enlazador, sin embargo, suele conocer, de forma muy limitada los tipos usados en los programas. Por ello, algunas de las violaciones de ODR no se detectan a la hora de implementar el lenguaje. Como resultado, es responsabilidad del programador el mantener la coherencia de todas las declaraciones que cruzan las fronteras de una unidad por traducir. Buscar todas estas declaraciones de una entidad externa y verficar que son compatibles de forma manual es una tarea ardua. (Nótese que C no define el término "one definition rule" — es específico del lenguaje C++. Si declaraciones de la misma entidad en muchos archivos fuentes de C son diferentes, la función no funcionará de forma adecuada y puede llegarse a un comportamiento impredecible, independientemente de la regla que se esté violando.)

Para entender una violación ODR, considérese el siguiente código (correcto):

 /* File print-heading.c */
 #include <stdio.h>
 
 void print_heading(void)
 {
   printf("standard heading\n");
 }

 /* File main.c */
 void print_heading(void);
 
 int main(void)
 {
   print_heading();
   return 0;
 }

La unidad por traducir representada por el archivo fuente main.c referencia a la función print_heading() que está definida en otra unidad por traducir (print-heading.c). De acuerdo con las reglas de C99, los programadores deben declarar una función externa antes del primer uso. Para cumplir con este requisito el archivo main.c declara la función en la primera línea. Esta versión del código funciona de forma correcta.

Posteriormente, el programador que mantiene el archivo fuente print-heading.c puede decidir hacer la función más flexible y dar soporte a cabeceras a gusto del usuario. Una posible implementación podría ser la siguiente:

 /* File print-heading.c */
 #include <stdio.h>
 
 void print_heading(const char *heading)
 {
   printf("%s\n", heading);
 }

Si el programador olvida actualizar la declaración en main.c, se pueden dar resultados devastadores. La función print_heading() espera un argumento y hace uso del valor del mismo, sin embargo la función main() no provee ningún valor. Al ejecutar este programa se produce un comportamiento impredecible: la aplicación puede imprimir basura, terminar de forma inesperada o dar pie a resultados impredecibles en la plataforma en la que es ejecutado.

¿Por qué se puede compilar y enlazar este código sin problema alguno? El motivo es que el compilador se guía por la declaración en main.c a la hora de compilar la unidad por traducir main.c. Y esa declaración se ajusta con la forma de la función. Más tarde, cuando el enlazador combina las unidades de traducción ya compiladas main.c y print-heading.c (en la mayoría de implementaciones representadas como archivos main.o o main.obj), probablemente podría detectar la inconsistencia  — pero no en C. Las implementaciones en C referencian las funciones por el nombre al nivel de archivo objeto y archivo binario, esto no incluye el valor de retorno o la lista de argumentos. El enlazador encuentra una referencia a print_heading() en main.o y una función adecuada en print-heading.o. Llegado este punto, toda la información relativa a tipos de argumentos de funciones se pierde.

¿Cómo es entonces posible llevar a cabo declaraciones múltiples sin problema alguno? La solución se llama header file. El header file de un módulo declara cada función, objeto y tipo de dato que forma parte de la interfaz pública del módulo — por ejemplo, en este caso el header file incluiría solo la delcaración de add. Todo aquel archivo fuente que se refiera a add usa la directiva #include en el header file:

 /* File add.h */
 #ifndef ADD_H
 #define ADD_H
 
 int add(int, int);
 
 #endif /* ADD_H */

(Nótese que el header file utiliza un "Include guard".)

 /* File triple.c */
 #include "add.h"
 
 int triple(int x)
 {
     return add(x, add(x, x));
 }

Esto reduce la carga del mantenimiento: cuando una definición cambia, solo se tiene que actualizar una única copia de la declaración (la del fichero de cabecera). El fichero de cabecera también se puede incluir en el fichero fuente que contiene las correspondientes definiciones, dándole al compilador la oportunidad de comprobar si la declaración y la definición son consistentes.

 /* File add.c */
 #include "add.h"
 
 int add(int a, int b)
 {
     return a + b;
 }

Normalmente, los programadores solo utilizan los header files para especificar las interfaces, y suelen aportar al menos, una pequeña cantidad de información explicando cómo usar los componentes declarados en el archivo. Al igual que en este ejemplo, las implementaciones de subrutinas permanecen en un archivo fuente separado, que continúa siendo compilado de forma independiente. (Una excepción común entre C y C++ son las "funciones inline", que suelen incluirse en header files porque la mayoría de implementaciones no pueden expendir funciones inline de forma adecuada sin ver sus definiciones durante el tiempo de compilación.)

Los header files no son la única solución al problema de acceder identificadores declarados en diferentes archivos. Tienen la desventaja de que los programadores siguen teniendo que realizar cambios en dos sitios diferentes (en el archivo fuente y en el header file) cuando se realiza un cambio en una definición. Algunos lenguajes más jóvenes (como Java) prescinden de los header files y usan, en su lugar, un esquema de nombres que permite al compilador localizar los archivos fuente asociados con implementaciones de clases e interfaces (pero, al hacerlo, se restringe la libertad a la hora de nombrar archivos). En estos lenguajes, el problema de ODR se suele resolver por medio de dos técnicas: la primera, el compilador pone toda la información necesaria sobre los tipos en el código compilado y esta información es accesible incluso cuando el programa se ejecuta; la segunda, Java y otros lenguajes modernos tienen la posibilidad de verificar el número y tipo de los argumentos como método de invocación. Todo esto tiene su precio: un exceso en espacio y tiempo de ejecución que no es aceptable para algunas aplicaciones donde el tiempo de respuesta es crítico.

COBOL y RPG IV tienen una forma de incluir archivos llamada copybooks. Los programadores "incluyen" estos en la fuente del programa de forma similar a como se hace con los header files, permitiendo también reemplazar ciertas partes del texto. La palabra clave de COBOL para la inclusión es copy, y el reemplazo se realiza por medio de la cláusula replacing...by.

• Application Programming Interface
• Interface description language
• #pragma once

• Esta obra contiene una traducción derivada de «Header file» de Wikipedia en inglés, publicada por sus editores bajo la Licencia de documentación libre de GNU y la Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional.
• Organizing Code Files (the potential pitfalls and guidelines for using header files in C++)
• C++ header file inclusion rules