Pour comprendre «en ligne», vous devez comprendre l'histoire et à quoi ressemblait la vie il y a 20 (et 30) ans.
Nous écrivions du code sur des ordinateurs qui avaient peu de mémoire, il n'était donc pas possible pour un compilateur de traiter tout le code qui composait un programme d'un seul coup. Le compilateur était également très lent, donc vous ne vouliez pas avoir à recompiler le code qui n'avait pas changé - prendre plus de 24 heures (sur un ordinateur qui coûte plus cher qu'une voiture haut de gamme) pour recompiler tout le code était normal pour quelques projets que je travaillé.
Par conséquent, chaque fichier de code a été compilé séparément dans un fichier objet. Chaque fichier objet a commencé avec la liste de toutes les fonctions qu'il contenait, ainsi que «l'adresse» de la fonction. Un fichier objet avait également une liste de toutes les fonctions qu'il appelait dans d'autres fichiers objet ainsi que l'emplacement de l'appel.
Un éditeur de liens lirait d'abord tous les fichiers objets, et constituerait une liste de toutes les fonctions qu'ils ont exportées, ainsi que le fichier dans lequel ils se trouvaient et leur adresse. Il relirait ensuite tous les fichiers objets, les exportant dans le fichier programme, tout en mettant à jour tous les appels de fonction «externes» avec l'adresse de la fonction.
L'éditeur de liens n'a pas modifié ou optimisé le code machine produit par le compilateur autrement que pour corriger les références aux appels de fonction externes. L'éditeur de liens faisait partie du système d'exploitation et est antérieur à la plupart des compilateurs. Lorsque les gens ont écrit un nouveau compilateur, ils en avaient besoin pour fonctionner avec les éditeurs de liens actuels et pour pouvoir se lier aux fichiers d'objets actuels, sinon les appels système ne pourraient pas être effectués.
Le compilateur n'a vu le code que dans le fichier «.c» ou «.cpp» qu'il compilait avec tous les fichiers d'en-tête inclus. Il n'a donc pas pu effectuer d'optimisation basée sur du code dans d'autres fichiers «.c» ou «.cpp».
Le mot-clé «inline» a permis de définir le corps d'une fonction (méthode) dans un fichier d'en-tête, permettant ainsi au compilateur d'utiliser le code de la fonction lors de la compilation du code qui l'appelle. Par exemple, supposons que vous ayez défini une classe de collection dans un autre fichier .cpp, cette classe aurait une méthode «isEmpty», qui contenait une ligne de code, il y aurait une grande accélération du programme résultant si, au lieu d'un appel à une fonction , l'appel de fonction a été remplacé par cette seule ligne.
Le mot-clé «en ligne» était perçu à l'époque comme un moyen «bon marché et facile» de permettre l'encapsulation des données tout en évitant le coût des appels de fonction, sans quoi beaucoup de programmeurs n'auraient qu'à accéder aux champs privés de l'objet. (Macros où une façon bien pire d '«aligner» le code était courante à l'époque.)
De nos jours, les «linkers» font beaucoup d'optimisation de code et ont tendance à être écrits par l'équipe en tant que compilateur. Souvent, le compilateur vérifie simplement que le code est correct et le «compresse», laissant l'essentiel de la tâche de création de code machine à l'éditeur de liens.