Une classe est déclarée dans des entêtes. Si cet entête change, même de manière anodine (par ex. ajout d'un saut de ligne pour aérer le code), alors cela va nécessiter la recompilation de tous les fichiers sources qui référencent directement ou indirectement ce fichier. Alors que si le fichier d'entête était "compilé" en un .class contenant juste l'ABI (et éventuellement le code pour les fonctions inline) de sorte d'avoir une représentation unique quelque soit l'organisation de l'entête, alors les temps de recompilation serait grandement réduit !
Même si les en têtes était pré compilé dans un fichier .class, une modification annodine de l'en-tête changerait aussi le fichier .class (ne fut-ce que le modtime) et forcerait aussi la recompilation de tous les fichier qui référencent directement ou indirectement ce fichier.
Oh! Et les en-tête précompilée ça existe déjà. Ça s'appelle .gch avec GCC et .pch avec clang. Et ça améliore effectivenement le temps de compilation car le compilateur ne dois pas recompiler le header pour chaque fichier qui le contiens.
Les entête pré-compilés ont leur propre problèmes, mais marchent assez bien en pratique.
[^] # Re: Retourne à la raison!
Posté par Gof (site web personnel) . En réponse au journal Retour aux sources. Évalué à 2.
Même si les en têtes était pré compilé dans un fichier
.class, une modification annodine de l'en-tête changerait aussi le fichier .class (ne fut-ce que le modtime) et forcerait aussi la recompilation de tous les fichier qui référencent directement ou indirectement ce fichier.Oh! Et les en-tête précompilée ça existe déjà. Ça s'appelle
.gchavec GCC et.pchavec clang. Et ça améliore effectivenement le temps de compilation car le compilateur ne dois pas recompiler le header pour chaque fichier qui le contiens.Les entête pré-compilés ont leur propre problèmes, mais marchent assez bien en pratique.
Mais l'avenir nous offre une solution presque parfaite: les Modules. Déjà partiellement implémentés dans clang.
http://clang.llvm.org/docs/Modules.html