Vous avez écrit du code. Ça marche. Mais maintenant, vous voulez utiliser ce générateur rand() ou cette routine bubble_sort dans un projet complètement différent. Le copier-coller est paresseux. C’est aussi fragile. Lorsque vous mettez à jour une version, vous devez rechercher chaque copie du code.
Le déménagement professionnel ? Construisez une bibliothèque.
Dans l’écosystème C, une bibliothèque n’est pas une boîte noire magique. Ce ne sont que deux dossiers portant des chapeaux différents. Vous avez besoin d’un fichier d’en-tête (.h ) et d’un fichier source (.c ). L’en-tête indique au reste du monde quelles fonctions existent. Le fichier source fait réellement le travail.
Construire l’interface : util.h
Le fichier d’en-tête fait office de contrat. Il ne contient pas la logique. Il contient les promesses. Constantes, types et prototypes de fonctions.
Créez un fichier nommé util.h.
Ces mots-clés « externes » font le gros du travail. Ils disent au compilateur : “Ne cherchez pas l’implémentation ici. Je la trouverai plus tard lors de la liaison.” Si vous êtes bloqué sur un compilateur existant antérieur aux normes C modernes, supprimez les paramètres de « bubble_sort ». Les anciens compilateurs sont pointilleux comme ça.
Cacher les machines : util.c
Passons maintenant au code réel. Enregistrez-le sous util.c.
Notez la directive include. Nous utilisons des guillemets ("util.h" ) au lieu de crochets angulaires (
Voici la partie subtile : rand_seed. Il se trouve dans util.c. Ce n’est pas dans util.h. Il s’agit d’informations cachées en action. Le code utilisant cette bibliothèque peut appeler rand(), mais il ne peut pas toucher directement la graine. L’État est encapsulé. Pour une application stricte, vous pouvez placer le mot-clé « static » devant la définition de la variable. Cela le verrouille fermement. Pas d’accès externe. Période.
Utilisation de la bibliothèque : main.c
Maintenant, écrivez le programme qui l’utilise. Enregistrez-le sous main.c.
Plus court ? Oui. Nettoyeur? Absolument. Le programme principal ne se soucie pas de la façon dont rand() génère les nombres. Cela demande juste un numéro. Cette séparation est tout le problème.
Compilation et liaison
Comment transformer ces fichiers séparés en un exécutable en cours d’exécution ? Vous suivez la danse en trois temps.
Tout d’abord, compilez la source de la bibliothèque dans un fichier objet. En supposant que vous utilisez un système de type UNIX utilisant GCC :
Le drapeau -c n’est pas négociable ici. Il indique au compilateur de s’arrêter après avoir produit le fichier objet. Il crée util.o. Ce fichier contient du code machine, mais il est incomplet. Il n’a pas de fonction « principale ». Il ne peut pas fonctionner tout seul. C’est un composant, pas un produit.
Ensuite, compilez votre programme principal :
Cela génère main.o. Encore une fois, juste du code machine. Toujours bloqué sans la logique de la bibliothèque.
Enfin, reliez-les ensemble.
Cette commande prend les deux fichiers objets et les assemble en un seul exécutable nommé « main ». Vous disposez désormais d’un programme complet. Exécutez-le avec ./main (ou simplement main si vous êtes sous Windows ou si vous l’avez sur votre chemin).
Cela fait beaucoup d’étapes pour deux fonctions. Mais imaginez faire cela pour un projet comportant cinquante fichiers. Vous compilez chaque fichier .c une fois. Vous les reliez ensemble. Changer une fonction dans la bibliothèque ? Recompilez uniquement ce fichier. Reconnecter. Le reste reste intact.
Les Makefiles automatisent cela
