Has escrito algún código. Funciona. Pero ahora quieres usar ese generador rand() o esa rutina bubble_sort en un proyecto completamente diferente. Copiar y pegar es una pereza. También es frágil. Cuando actualizas una versión, debes buscar cada copia del código.
¿El movimiento profesional? Construye una biblioteca.
En el ecosistema C, una biblioteca no es una caja negra mágica. Son sólo dos archivos con sombreros diferentes. Necesita un archivo de encabezado (.h ) y un archivo fuente (.c ). El encabezado le dice al resto del mundo qué funciones existen. El archivo fuente realmente hace el trabajo.
Construyendo la interfaz: util.h
El archivo de encabezado actúa como contrato. No contiene la lógica. Contiene las promesas. Constantes, tipos y prototipos de funciones.
Cree un archivo llamado util.h.
Esas palabras clave “externas” están haciendo un trabajo pesado. Le dicen al compilador: “No busque la implementación aquí. La encontraré más tarde durante la vinculación”. Si está atrapado en un compilador heredado anterior a los estándares C modernos, elimine los parámetros de bubble_sort. Los compiladores antiguos son así de exigentes.
Ocultar la maquinaria: util.c
Ahora para el código real. Guarde esto como util.c.
Observe la directiva de inclusión. Usamos comillas ("util.h" ) en lugar de corchetes angulares (
Aquí está la parte sutil: rand_seed. Se encuentra en util.c. No está en util.h. Esta es información oculta en acción. El código que usa esta biblioteca puede llamar a rand(), pero no puede tocar la semilla directamente. El Estado está encapsulado. Para una aplicación estricta, puede colocar la palabra clave “estática” delante de la definición de la variable. Eso lo bloquea firmemente. Sin acceso externo. Período.
Usando la biblioteca: main.c
Ahora, escribe el programa que lo utiliza. Guarde esto como main.c.
¿Más corto? Sí. ¿Limpiador? Absolutamente. Al programa principal no le importa cómo rand() genera números. Sólo exige un número. Esa separación es el punto central.
Compilación y vinculación
¿Cómo se convierten estos archivos separados en un ejecutable en ejecución? Sigues el baile de tres pasos.
Primero, compile el código fuente de la biblioteca en un archivo objeto. Suponiendo que estás en un sistema tipo UNIX usando GCC:
La bandera -c no es negociable aquí. Le dice al compilador que se detenga después de generar el archivo objeto. Crea util.o. Este archivo contiene código de máquina, pero está incompleto. No tiene función “principal”. No puede funcionar por sí solo. Es un componente, no un producto.
A continuación, compila tu programa principal:
Esto genera main.o. Nuevamente, solo código de máquina. Todavía estancado sin la lógica de la biblioteca.
Finalmente, vincúlelos.
Este comando toma ambos archivos objeto y los une en un único ejecutable llamado “principal”. Ahora tienes un programa completo. Ejecútelo con ./main (o simplemente main si está en Windows o lo tiene en su ruta).
Son muchos pasos para dos funciones. Pero imagina hacer esto para un proyecto con cincuenta archivos. Compila cada archivo .c una vez. Los vinculas entre sí. ¿Cambiar una función en la biblioteca? Vuelva a compilar solo ese archivo. Vuelva a vincular. El resto permanece intacto.
Makefiles automatiza esto
