Bien qu'ils puissent vous être utiles comme forme de documentation, le système entourant les fichiers d'en-tête est extrêmement inefficace.
C a été conçu pour que chaque étape de compilation crée un seul module; chaque fichier source est compilé dans une exécution distincte du compilateur. Les fichiers d'en-tête, en revanche, sont injectés dans cette étape de compilation pour chacun des fichiers source qui les référencent.
Cela signifie que si votre fichier d'en-tête est inclus dans 300 fichiers source, il est analysé et compilé encore et encore, 300 fois pendant la construction de votre programme. La même chose avec le même résultat, encore et encore. C'est une énorme perte de temps, et c'est l'une des principales raisons pour lesquelles les programmes C et C ++ sont si longs à construire.
Toutes les langues modernes évitent intentionnellement cette absurde petite inefficacité. Au lieu de cela, généralement dans les langues compilées, les métadonnées nécessaires sont stockées dans la sortie de génération, permettant au fichier compilé d'agir comme une sorte de référence de recherche rapide décrivant ce que contient le fichier compilé. Tous les avantages d'un fichier d'en-tête, créé automatiquement sans travail supplémentaire de votre part.
Alternativement dans les langages interprétés, chaque module qui est chargé reste en mémoire. Référencer ou inclure ou nécessiter une bibliothèque lira et compilera le code source associé, qui restera résident jusqu'à la fin du programme. Si vous en avez également besoin ailleurs, aucun travail supplémentaire car il a déjà été chargé.
Dans les deux cas, vous pouvez "parcourir" les données créées par cette étape à l'aide des outils de la langue. Typiquement, l'EDI aura un navigateur de classe quelconque. Et si le langage a un REPL, il peut aussi souvent être utilisé pour générer un résumé de la documentation de tous les objets chargés.