Rob Pike en avait marre de lancer des compilations interminables.
Il dit par exemple que [#include "stdio.h"] ouvre 1000 fichiers. Les macros de gardes dans les includes ont des effets très limités.
On peut lire aussi les articles de l'auteur du langage D à ce sujet. Il a des raisons similaires. On ne peut pas réellement accélérer la compilation a cause des includes et des macros. N'importe quelle ligne peut être modifiée par une macro qui a sont tour peut modifier les includes...
Depuis que j'ai lu ça, je ne compile plus qu'un fichier. J'ai un "main.cpp" qui inclut un ensemble d'arborescence de sources. C'est structuré.
Ca parait fou mais c'est beaucoup plus efficace. Tout est en mémoire. La compilation est ultra-rapide. Pas de link autre que avec les librairies standards.
Pas besoin de make non plus. Gros avantage.
Je pense qu'il y a une limite à cause de la mémoire. Je ne l'ai pas encore atteinte.
[^] # Re: Pas de "bonne" réponse
Posté par keyser.dyson . En réponse au journal Python comme premier langage de programmation ?. Évalué à 3.
C'est une des justifications de Go.
Rob Pike en avait marre de lancer des compilations interminables.
Il dit par exemple que [#include "stdio.h"] ouvre 1000 fichiers. Les macros de gardes dans les includes ont des effets très limités.
On peut lire aussi les articles de l'auteur du langage D à ce sujet. Il a des raisons similaires. On ne peut pas réellement accélérer la compilation a cause des includes et des macros. N'importe quelle ligne peut être modifiée par une macro qui a sont tour peut modifier les includes...
Depuis que j'ai lu ça, je ne compile plus qu'un fichier. J'ai un "main.cpp" qui inclut un ensemble d'arborescence de sources. C'est structuré.
Ca parait fou mais c'est beaucoup plus efficace. Tout est en mémoire. La compilation est ultra-rapide. Pas de link autre que avec les librairies standards.
Pas besoin de make non plus. Gros avantage.
Je pense qu'il y a une limite à cause de la mémoire. Je ne l'ai pas encore atteinte.