Discussion :

[Paul TOTH]

je suis content de lire cela pour une fois

en général on me répond que le programmeur C++ passe plus de temps à réfléchir et à coder, le temps de compilation importe peu car on ne passe pas son temps à modifier une ligne et à recompiler. Je me disais, mince ils sont rudement forts ces développeurs C++, moi je passe mon temps à compiler mon projet, non seulement ça m'évacue les erreurs de syntaxe, mais en plus je peux tester mon projet bout par bout.

Mais sous Delphi les temps de compilation sont complètement négligeables, je me souviendrais toujours d'un blog de développeur C++ qui testai Delphi pour la première fois :

J'appuie sur Ctrl+F9 pour lancer la compilation...rien ne se passe. Je vais dans le Projet/Compiler sans plus de succès...en fait il m'a fallut 1/4h pour comprendre que le projet était effectivement compilé et qu'il suffisait alors de l'exécuter !

[Klaim]

En fait c'est vrai qu'on réfléchis plus parcequ'avant de lancer la compilation on veut vérifier qu'elle ne vas pas être fouarreuse (au bout de 10 minutes) juste parcequ'on a oublié un point virgule...
En un sens c'est une bonne chose, mais c'est vrai que rien ne vaut un bon retour (feedback) rapide.

[Klaim]

Au passage, la dicussion très récente sur Ogre concernant l'Unity Build qu'ils expérimentent actuellement. Il y a des retours de performance assez hallucinants :

http://ogre3d.org/forums/viewtopic.php?f=4&t=64175

[_skip]

Mais ça veut dire que si toutes les sources de ton projet sont mergées en 1 seul fichier, à chaque modification tu recompiles l'intégralité du code. Donc ok pour compiler des sources complètes qu'on vient de télécharger mais quid du développement avec compilation incrémentale?

[Klaim]

Oui ça fait parti des contre-couts (voir le liens stackoverflow qui mène là : http://buffered.io/2007/12/10/the-ma...-unity-builds/ ) .

C'est utile par exemple si tu maintiens une bibliothèque et que tu veux tester des patchs.

Par contre si ton projet est globalement bien divisé ou qu'il n'est pass hyper meta-templaté, il se peut que ta build dure quelques secondes...auquel cas c'est tout benef.

Dans tous les cas c'est surtout utile pour du débuggage, pas pour le développement habituel.

D'où la nécessité d'avoir un système plus fondamental que ce bricolage pour arriver à des compilation décentes (d'où système de module).

J'ai envoyé un mail l'autre jour à celui qui à fait la proposition concernant le système de module en C++. A sa connaissance il n'y a pas de projet publique pour implémenter experimentallement le système. Vu qu'il y en a qui implémentent les Concepts dans CLang (vu sur la mailing list) il se peut que quelqu'un s'y mette pour les modules quand on commencera à se remettre dessus dans le commité (autrement dit a partir de l'année prochaine ou de la fin de cette année si j'ai bien compris).

Si j'avais pas whatmille projets en cours je me serais certainement lancé dans Clang pour tenter d'implémenter le truc. Par contre c'est pas une feature très simple a faire parceque ça touche à la logique de compilation, evidemment.

[_skip]

Et aussi ça suppose que les macros comme __LINE__ soient traités avant le merge définitif...

[Klaim]

Ouaip.

Faut aussi que les objets statiques non-globaux aient des noms différents...puisqu'il n'y a plus qu'une seule unité de compilation.

Donc clairement, c'est du hack, utile dans certains cas seulement, et parcequ'on a pas vraimen d'alternative aussi efficace, et c'est "pas normal"

[Franck Z]

Je me souviens d'un livre écrit par le codeur initial de Doom qui parlait des conséquences désastreuses quand on écrit un programme qui calcule un checksum sur un fichier sans prêter attention aux buffers et clusters qui se cachent derrière les fonctions I/O de la bibliothèque de C.

On ne pourrait pas en fait déléguer le problème aux programmeurs d'OS et imaginer une solution intermédiaire entre le disque RAM et l'unity build en améliorant la gestion des buffers I/O du système d'exploitation pour qu'ils durent le temps de l'exécution du makefile, plutôt que seulement le temps de l'exécution de chaque commande gcc ?

[Franck Z]

Pour l'histoire de recompilation des headers, si je suppose (naïvement, sans doute) qu'un compilateur organise sa compréhension du code qu'il compile, c-à-d. la sémantique des différents identificateurs qu'il doit manipuler, autour d'objets pour chaque identificateur, alors (en considérant que le "contrat" de base d'un objet dans un programme, c'est de conserver la sémantique de cet objet, à partir du moment où il a été instancié par son constructeur, quelque soit l'endroit (invariance par rapport au temps) où on l'appelle dans le programme par la suite) il suffirait de mettre en place une possibilité de marshalling (sérialisation) de ces objets entre les différentes commandes gcc lancées par make, grâce au fait que make est un processus "parent" pour les exécutions de gcc.

D'une part, on ne viole pas la philosophie de make : servir de lien pour une sérialisation ne signifie pas comprendre ce qu'on transmet.
D'autre part, pour peu que l'utilisateur s'engage à ne pas corrompre les fichiers sources pendant l'exécution du makefile, les ambiguïtés pour un même identificateur ne doivent pas être si difficiles à lever que cela, non ? Ca ne va guère plus loin que le nom du fichier source et l'environnement (c-à-d., un nombre fini de "defines" et d'autres identificateurs, levés eux-aussi de leurs ambiguïtés) où la compilation de la définition de cet identificateur a eu lieu.
En plus pour l'utilisateur du makefile, c'est transparent et il n'a pas à se restreindre dans son usage du C++.

Mais c'est sûr que le compilateur est plus à même de faire ce travail qu'un programme réalisé par une tierce-partie, comme dans le cas des unity builds.

Il ne reste plus que la complexité de la grammaire du C++. Mais il ne faut pas jeter non-plus le bébé avec l'eau du bain. Toucher au langage lui-même, c'est risquer de le perdre...

Enfin, bon... je m'avance peut-être un peu, là ?

[Paul TOTH]

le problème c'est qu'en C/C++ les headers sont ce qu'on veux bien y mettre, elles peuvent être déclaratives ou contenir du code, elles sont simplement incluses dans le code. De plus, le linker est lancé après la compilation, c'est à lui de recoller les morceaux; le compilateur s'est contenté de déclarations externes sans se poser de question.

dans la logique Pascal, tout ce que rencontre le compilateur est obligatoirement identifié car déclaré en amont. De plus chaque source (unité) constitue un espace de noms unique, il n'y a donc jamais collision entre les noms. Cette structure est souvent critiquée notamment en ce qui concerne l'interdiction des références circulaires (unité A qui utilise unité B qui utilise unité A) mais c'est diablement efficace pour la compilation.

[Lung]

Cette structure est souvent critiquée notamment en ce qui concerne l'interdiction des références circulaires (unité A qui utilise unité B qui utilise unité A) mais c'est diablement efficace pour la compilation.

J'ai jamais compris ce que ça voulait dire.
J'ai souvent une unité A qui utilise unité B qui utilise unité A, sans problème. Il suffit juste de bien placer ses uses.

[Paul TOTH]

dans la pratique je tombe rarement sur cette limitation mais elle existe bien.

voir mon article sur le sujet.

[Franck Z]

dans la pratique je tombe rarement sur cette limitation mais elle existe bien.

voir mon article sur le sujet.

Ce lien (que je trouve très intéressant, de fait) résume bien, pour moi, le côté injuste de la critique dans l'article initial de Walter Bright.

Elle donne l'impression qu'il y aurait une fatalité dans la lenteur de la compilation C++, sans dire clairement quel est son bénéfice, et mélange le côté techniques d'écriture des compilateurs et place du langage en génie logiciel.

Mais, quand je lis le lien, je ne peux m'empêcher de faire un rapprochement avec certains problèmes des physiciens théoriciens... Je m'explique :

• On dispose d'un langage à un autre de possibilités d'expressions diverses, mais sans doute équivalentes avec de la pratique.
• Le coût intellectuel pour le développeur n'est pas équivalent.

Pour des raisons personnelles, je me replonge en ce moment sur la différence entre point de vue hamiltonien et point de vue lagrangien en physique (notamment le livre "Calcul variationnel" et J.-P. Bourguigon (Eclipse)). Les lois de la physique classique s'expriment à notre échelle aussi bien en termes de lagrangiens qu'en termes de hamiltoniens. Pourtant, pour faire le pont entre la physique classique et la physique quantique, il faut passer par la formulation hamiltonienne, sinon on échoue. A contrario, le passage vers la relativité générale semble plus aimer les formulations lagrangiennes. Et cerise sur le gâteau, les physiciens échouent à unifier en une seule théorie la mécanique quantique et la relativité générale.

Et là je trouve qu'il faut observer que C et C++ ont eu un rôle prépondérant précisément pour défricher et commencer la conceptualisation du monde physique, tel qu'il se présente à l'informatique. Ainsi, la programmation système, les premières bibliothèques utilisant les processeurs à coeurs multiples (TBB) et l'analyse numérique sont passées abondamment par C/C++ pour accéder à une forme de maturité.

Est-ce vraiment un hasard ? ou bien existe-t-il une raison profonde comme pour la problématique de physique théorique que j'ai résumée ici, qui fait que l'équivalence d'expressivité entre langages (comme dans le lien en référence) est mauvaise conseillère et que critiquer sans discernement le modèle headers/sources de C++ est injuste ?

[Paul TOTH]

tu peux me la refaire ? je crains de ne pas avoir saisi les subtilités de ton commentaire.

[Franck Z]

Désolé, j'ai été un peu brutal par rapport à ce qui me trotte dans la tête ces temps-ci...

Par exemple, imaginons un programmeur qui a atteint un certain point de développement de son application. Il lui vient une idée et observe que son code peut se réécrire à l'aide de deux objets A et B qui se définissent l'un par rapport à l'autre comme dans les exemples que tu discutes.

Je suis tenté d'utiliser le langage de la physique : il voit une symétrie A-B dans ses traitements et variables.

Et là, les deux langages C++ et Delphy diffèrent dans leurs réponses.

- C++ accepte cette symétrie sans broncher grâce à la structure headers/code puis édition de liens.
- Delphy lui demande de briser la symétrie qu'il souhaite introduire dans son code, au niveau de ses déclarations. S'il cherche à la conserver quand même, il doit faire un effort d'abstraction comme dans les exemples que tu donnes.

Ca peut paraître anodin, certes. Mais :

• d'une part, il existe peut-être cette situation, comme en physique théorique, où exprimer une version plus abstraite de la symétrie initiale A-B ne colle pas trop avec les tenants de la théorie elle-même (bon, d'accord, en info, cela paraît un point de vue extrême)
• mais d'autre part, pour un programmeur qui traite d'un sujet nouveau en informatique, son idée est contrée par Delphy et il doit programmer une symétrie dans son programme en la brisant d'emblée. C'est au minimum perturbant.

Je me dis que dans les cas où l'on défriche un domaine, c'est une charge intellectuelle qu'on pourra fuir.

Pour l'histoire Lagrangien vs. Hamiltonien, c'est sans doute très abusif de ma part. (en fait, j'avais posé une question pour savoir si ces concepts avaient une place en informatique théorique, notamment pour expliquer ce qu'est un objet, mais ma question a été bloquée par un modérateur).

L'idée des lagrangiens, c'est, alors qu'on travaille dans un espace donné, de considérer des calculs le long de chemins dans cet espace. Ces ensembles de chemins peuvent présenter des propriétés que l'on exploite : c'est le cas des géodésiques qui minimisent ou maximisent une mesure de distance de long de ces chemins (cf relativité).

Le côté hamiltonien, c'est plutôt d'affiner la structure de l'espace dans lequel on travaille par des considérations de symétries, jusqu'à pouvoir décrire d'une manière algébrique les solutions du problème. (cf mécanique quantique, mais on n'est pas obligé d'aller jusqu'à ce cas extrême)

Je suis un peu habité par l'idée que le monde de l'objet en programmation participe beaucoup de ce côté hamiltonien : définir un objet dans un programme, c'est exprimer l'idée d'un invariant (sémantique) au cours de l'exécution du programme.

Pardon si je dérape un peu...

[Paul TOTH]

oui mais tu passes à côté du théorème d'incomplétude de Gödel

ceci dit, je développe en Pascal depuis à peu près 20 ans, et les références circulaires n'ont jamais été un obstacle dans mes développements.

d'autant que la solution la plus évidente est de déclarer les deux objets dans la même unité, ce qui n'est pas absurde quand ils sont liés au point de se référencer mutuellement.

maintenant je doute que cette seule limitation soit la clé de la performance des compilateurs pascal...et la cause de la lenteur des compilateurs C++.

[Klaim]

Les raisons techniques qui font que le C++ est long à compiler sont liées à sa structure complexe et sa manière de gérer les unités de compilation. Ce dernier point peut largement être amélioré, comme l'indique la proposition sur les modules (qui rendrait la compilation presque semblable à celle de C# ou Java, mais en gardant le système actuel -- restant donc compatible avec le code actuel).

Donc c'est juste au niveau du standard qu'il faut changer des choses. Il n'y a pas de bonne raison pour avoir un système aussi lent.

[Franck Z]

Je me suis amusé à télécharger le source de gcc (ouf... il y a du monde !) pour voir... (grosse claque )

Apparemment, je suppose pour des raisons de vitesse d'exécution, il ont conservé un automate à piles. Ce n'est pas évident de savoir s'il est possible de sérialiser facilement les résultats de compilation comme dans mon message un peu plus haut ou s'il faudrait une refonte du code source pour y arriver.

C'est pas comme si je pouvais faire ça dans mon coin et le leur proposer.

[Klaim]

Si tu veux voir un compilo 1. récent 2. pensé pour une compilation rapide 3. pensé pour être lisible, télécharge plutot le source code de clang http://clang.llvm.org/

[Paul TOTH]

Sinon question rapidité de compilation il y a TCC qui est un compilateur C une passe...par contre le code produit n'est pas ultra optimisé.