Discussion :

[Franck Z]

(juste en trois mots : en fait, pour Gödel, je l'avais un peu mis de côté parce que les probabilités ne sont pas gênées apparemment si au lieu de prendre des tribus (sigma-algèbres) on ne prend que des sigma-anneaux : la différence entre les deux, c'est qu'on ne suppose plus cet ensemble stable par passage au complémentaire, mais juste par différence entre ensembles, c-à-d. A \ B si A et B sont supposés dans le sigma-anneau. Et pour construire les énoncés qui posent problème avec Gödel, il faut supposer que les ensembles de propositions manipulés sont stables par la négation.

Mais regarder "sous le capot" de toutes ces théories pour vérifier, c'est un peu "gros" pour moi. Je garde juste un oeil attentif au cas où je croiserais un contre-exemple un jour... )

ps : merci pour les liens.

[Klaim]

A propos de l'unity build, un article expliquant tous les problèmes liés et aussi pourquoi c'est une solution au mauvais problème : http://altdevblogaday.com/2011/08/14...-unity-builds/

[loufoque]

Il me semble que cela n'a pas déjà été dit, mais de nombreux compilateurs détectent déjà les fichiers dont le pattern est ifndef define ... endif et les gèrent comme des includes symboliques pour accélérer la compilation.

[Emmanuel Deloget]

Je ne suis pas un spécialiste barbu du c++, juste un nouvel utilisateur depuis peu, quelques heures à mon actif.

Et je dois bien dire que les include sont infâmes. D'ailleurs je ne comprend pas pourquoi il faut que j'indique l'usage de la classe <machin>, c'est écris dans le code, le compilo n'à qu'à lire pour le déterminer, rien de bien sorcier.

Les seules raisons qui devraient me pousser à faire cette définition explicite seraient de vouloir forcer une version, mais d'autres mécanismes doivent déjà exister.

d'utiliser des types "dynamique", mais est ce qu'on s'en sert si souvent ? Et est ce que lorsqu'on s'en sert ce n'est pas au développeur de l'indiquer explicitement.

Par ailleurs, au sein d'un même projet genre gui, pas trop gros cela va de soit, on pourrait avoir un seul include sa éviterait les duplications...

De la même manière le compilateur n'émet pas de message lorsque une librairie est chargée inutilement.

Enfin je ne comprend pas pourquoi ce genre d'update devrait attendre une dizaine d'années.... C'est pas une tâche du compilateur sa ? Suffit pas de faire un patch?....

De mon oeil de novice qui n'y connait pas grand chose, tout cela me laisse un goût de jm'en foutisme, particulièrement lorsque je lis ceci :


a plus

C'est original comme message.

Bon, point par point :

Je ne suis pas un spécialiste barbu du c++, juste un nouvel utilisateur depuis peu, quelques heures à mon actif.

Du coup, moins qualifié que d'autre pour parler des forces et faiblesses du langage. Le système de compilation du C++ est lent, on ne peut pas le nier, mais cette lenteur est en grande partie due aux forces intrinsèques du langage - template, etc. Du coup, ne pas connaître le langage rends l'appréciation de ses limites et des conséquences sur le modèle de compilation hasardeuse. Mais oublions ce point, car il n'a que peu d'intérêt.

Et je dois bien dire que les include sont infâmes. D'ailleurs je ne comprend pas pourquoi il faut que j'indique l'usage de la classe <machin>, c'est écris dans le code, le compilo n'à qu'à lire pour le déterminer, rien de bien sorcier.

Impossible au vu du modèle de compilation. Un élément qui n'est pas déclarer avant d'être utilisé est impossible à identifier correctement avant la phase de lien, ce qui n'est pas une bonne chose (ça reviendrais à compiler systématiquement tout le projet avant de pouvoir détecter 90% des erreurs). Ce n'est pas acceptable - d'où la présence des headers (qui ne contiennent pas que des classes, et qui peuvent contenir plusieurs classes si nécessaire ; de plus, la classe machin n'est pas nécessairement définie dans <machin>).

Les seules raisons qui devraient me pousser à faire cette définition explicite seraient de vouloir forcer une version, mais d'autres mécanismes doivent déjà exister.

Nope. La raison est la validation syntaxique du code. Deux problèmes sont à résoudre : la grammaire ambigüe du C++ fait que des expressions semblables peuvent avoir un traitement fort différent selon le type des symboles utilisé, ou que certaines expressions n'ont pas de sens.

identifier1 identifier2;

est une déclaration de variable si identifier1 est un type, sinon une erreur de syntaxe doit être générée. Et comment savoir si identifier1 est un type ou non sans connaître le symbole ?

Le second problème est lié à la surcharge des fonctions (et des opérateurs).

c = a + b;

Peut faire intervenir deux surcharges (operator=, operator+) ainsi que des conversions implicite de type qui peuvent elles aussi être surchargées.

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
std::string s1, s2("yy"); 
const char* s2 = "xx";
 
s1 = s2 + s3;
// s1 == "yyxx"

Comment le compilateur peut-il savoir s'il doit générer du code pour une addition (opcode assembleur ADD ou assimilé) ou s'il doit appeler une fonction (CALL) ? S'il veut pouvoir faire le choix, il lui faut connaître le détail des types utilisé. Sans header, cela reviendrait à réécrire le header de manière systématique dans tous les fichiers qui l'utilise.

d'utiliser des types "dynamique", mais est ce qu'on s'en sert si souvent ? Et est ce que lorsqu'on s'en sert ce n'est pas au développeur de l'indiquer explicitement.

Par ailleurs, au sein d'un même projet genre gui, pas trop gros cela va de soit, on pourrait avoir un seul include sa éviterait les duplications...

Je ne comprends pas ce que tu veux dire.

De la même manière le compilateur n'émet pas de message lorsque une librairie est chargée inutilement.

Pour la simple et bonne raison que c'est au linker de le faire, et pas au compilateur. Ca ne fait pas partie du langage. Le compilateur a simplement pour but d'interpréter correctement le programme, et de générer une sortie qui sera comprise par le linker. Le reste est du ressort d'autres outils de la chaine qui n'ont rien à voir avec le C++ (le linker GNU (ld) est utilisé par d'autres toolchain : C, fortran, pascal,...).

Enfin je ne comprend pas pourquoi ce genre d'update devrait attendre une dizaine d'années.... C'est pas une tâche du compilateur sa ? Suffit pas de faire un patch?....

Euh... J'ai du mal à comprendre ce passage. La mise à jour de la norme C++ est suffisamment importante pour avoir nécessité des années de travail. Sans cette norme, aucun compilateur ne fonctionnerait de la même manière et les programmes C++ ne seraient pas portables d'un compilateur à l'autre. Ce n'est pas à un vendeur de compilateur de dicter sa loi sur le marché, surtout lorsque le langage ne lui appartient pas (il peut le faire s'il veut, mais il va développer son produit en pure perte : personne de censé ne l’achètera).

Et faire un patch à quoi ? Au compilateur ? Lequel ? Celui d'Intel, celui de GNU, celui de Microsoft, le front end de EGC, celui de Commeau, celui de Digital Mars, celui de Codeplay, etc... ?

Ca va faire un gros patch, avec beaucoup de binaire dedans...

De mon oeil de novice qui n'y connait pas grand chose, tout cela me laisse un goût de jm'en foutisme, particulièrement lorsque je lis ceci :

Le fait que les plus grand experts du monde se soient penchés pendant 10 ans sur le problème de le mise à jour du standard du C++ te laisse un goût de "jm'en foutisme"? Il faudrait peut être que tu ailles les aider alors, parce que ça, ça me laisse sans voix.

[PhilIvey]

C'est original comme message.

Du coup, moins qualifié que d'autre pour parler des forces et faiblesses du langage. Le système de compilation du C++ est lent, on ne peut pas le nier, mais cette lenteur est en grande partie due aux forces intrinsèques du langage - template, etc. Du coup, ne pas connaître le langage rends l'appréciation de ses limites et des conséquences sur le modèle de compilation hasardeuse. Mais oublions ce point, car il n'a que peu d'intérêt.

Il faut pas exagérer et justifier un archaïsme hérité ( le système de compilation) par un ajout "récent" du langage.

Le système de compilation du C++ et la syntaxe ambiguë sont les deux faiblesses du langage. Ils rendent moins attractifs certaines forces du langage, comme les templates. Quant je vois que certains de nos projets c# font massivement appel aux generics, alors que l'utilisation des templates est toujours fortement encadrée sur les projets C++, que certains bibliothèques de Boost (MPL,etc...) sont interdites, alors qu'elles serait la solution localement sur certains composants.

Il ne faut pas chercher bien loin le coupable.

[koala01]

Il faut pas exagérer et justifier un archaïsme hérité ( le système de compilation) par un ajout "récent" du langage.

Le système de compilation du C++ et la syntaxe ambiguë sont les deux faiblesses du langage. Ils rendent moins attractifs certaines forces du langage, comme les templates. Quant je vois que certains de nos projets c# font massivement appel aux generics, alors que l'utilisation des templates est toujours fortement encadrée sur les projets C++, que certains bibliothèques de Boost (MPL,etc...) sont interdites, alors qu'elles serait la solution localement sur certains composants.

Il ne faut pas chercher bien loin le coupable.

Là, c'est toi qui exagère en rendant le langage responsable des faiblesses de certains utilisateurs en termes de conception...

Je suis tout à fait d'accord que C++ est lent à la compilation et que c'est un langage qui, revers des libertés qu'il offre, nécessite un respect plus stricte des principes de programmation, d'encapsulation et de POO...

Je travaille personnellement sur un projet important, on ne peut plus pro, mais dans une équipe (un minimum en tout cas) compétante, et on bouffe massivement des template et du boost à foison!!!

Avant d'en arriver à rendre le langage ou les bibliothèques responsables de certaines restrictions imposées dans un projet particulier, commence peut être par t'interroger sur les faiblesses et la (l'in) compétence des responsables de projet et / ou des développeurs de l'équipe

[PhilIvey]

Là, c'est toi qui exagère en rendant le langage responsable des faiblesses de certains utilisateurs en termes de conception...

Je suis tout à fait d'accord que C++ est lent à la compilation et que c'est un langage qui, revers des libertés qu'il offre, nécessite un respect plus stricte des principes de programmation, d'encapsulation et de POO...

Je travaille personnellement sur un projet important, on ne peut plus pro, mais dans une équipe (un minimum en tout cas) compétante, et on bouffe massivement des template et du boost à foison!!!

Si tu relis bien mon post, je ne parle que du système de compilation, et de la syntaxe ambiguë.Si tu trouves des bénéfices au système de compilation et à la lenteur que ça induit, je serai heureux de les connaitre.

Tout ce que je dis , c'est que c'est un frein à la généralisation de certaines best practices, à l'utilisation massive des templates. Dis moi, si je me trompe , mais tu dois passer un temps certain à faire de l'optimisation de temps de compilation( pch,pre-instantation,etc..). Un système de modules ferait un bien fou au langage, sans perdre en puissance

Notre projet principal, utilise plusieurs centaines de développeurs, répartis aux quatres coins du monde; tu as besoin de règles plus strictes,pour gérer l’hétérogénéité des développeurs,et maitriser le projet.

Le pragmatisme c'est aussi une forme de compétence technique.....

[JolyLoic]

Je suis d'accord que le système de compilation n'est pas bon (performances, apprentissage, encapsulation...), je pense même que c'est ce qu'il faudrait améliorer en priorité en C++.

Néanmoins j'ai du mal à voir le lien entre ce système et une limitation de l'utilisation des templates. Là où j'ai vu des règles sur les templates, les raisons étaient plus liées à un mauvais support par certains compilateurs (parfois des compilaeur plus utilisés dans le projet depuis 10ans...) et/ou à un manque de formation qu'à quoi que ce soit lié à la chaîne de compilation. Pourrais-tu développer ?

[Emmanuel Deloget]

Je suis d'accord que le système de compilation n'est pas bon (performances, apprentissage, encapsulation...), je pense même que c'est ce qu'il faudrait améliorer en priorité en C++.

Néanmoins j'ai du mal à voir le lien entre ce système et une limitation de l'utilisation des templates. Là où j'ai vu des règles sur les templates, les raisons étaient plus liées à un mauvais support par certains compilateurs (parfois des compilaeur plus utilisés dans le projet depuis 10ans...) et/ou à un manque de formation qu'à quoi que ce soit lié à la chaîne de compilation. Pourrais-tu développer ?

Sur un gros (gros) projet, une utilisation abusive des templates peut très nettement malmener le temps de compilation. Je pense que c'est à _a qu'il fait référence.

[koala01]

Il est vrai que l'on utilise la compilation partagée, et que cela réduit considérablement les temps de compilation (qui seraient horribles autrement).

Mais je voulais surtout mettre en évidence le fait que, bien que le processus de compilation soit très lent -- chose qu'il est d'ailleurs possible de contourner -- les premières raisons invoquées pour éviter les template et boost auront souvent trait au manque de maitrise dont fait preuve celui qui les donne

[PhilIvey]

Mais je voulais surtout mettre en évidence le fait que, bien que le processus de compilation soit très lent -- chose qu'il est d'ailleurs possible de contourner -- les premières raisons invoquées pour éviter les template et boost auront souvent trait au manque de maitrise dont fait preuve celui qui les donne

Koala,

Comme l'a compris E. Deloget
Je dis juste ,qu'une utilisation intensive des templates peut avoir un effet désastreux sur les temps de compilation,

Si tu lis encore une fois mon post initial, je ne dis que que les templates ou Boost sont interdits, mais
que l'utilisation est encadrée, et que certaines librairies Boost sont interdites...

Notre code de base est ancien,( fin des années 90), et nous avons entrepris il y a quelques années, de nettoyer certaines parties,
et de rendre l'architecture plus flexible aux modifications.

Une des solutions se basait sur Boost MPL,boost::enable_if , pour certaines factories, et Boost Fusion pour génériser les traitements en sortie de parsing.

C’était la solution la plus concise et élégante, et celle qui permettait le maximum de vérification statique du code mais l'impact sur les temps de compilation a été proprement calamiteux.

Pour te donner un indicateur très imparfait, le soft installé sur le poste client peut atteindre 10 Go...
Tout n'est pas bien sur en C++.... .
Tu te doutes bien que nous utilisons une solution de compilation partagée.
Boost est bien sur très présent; dans des biens des cas c'est strictement équivalent à un simple include.

Si tu utilises d'autres languages ( c# ou D) , tu as du te rendre compte, que programmation générique et metaprog n’équivalaient pas à temps de compilation longs...

[gorgonite]

Si tu utilises d'autres languages ( c# ou D) , tu as du te rendre compte, que programmation générique et metaprog n’équivalaient pas à temps de compilation longs...

métaprogrammation intégré au langage en C#

ok pour D (qui a "appris" des défauts de C++ ^^)

[PhilIvey]

métaprogrammation intégré au langage en C#

ok pour D (qui a "appris" des défauts de C++ ^^)

Tout depend de ta definition de la metaprogrammation , qui est possible
en C++ et D par le biais des templates.

La reflection, qui fonctionne aussi avec les generics, c'est une forme de metaprogrammation.

[gorgonite]

Tout depend de ta definition de la metaprogrammation
[...]
La reflection, qui fonctionne aussi avec les generics, c'est une forme de metaprogrammation.

forcément si chacun peut définir comme il le souhaite les notions qui l'arrangent

en C#, la "reflexion" est surtout limitée à l'introspection non ?
hors, il faut aussi intercession de SmallTalk pour réellement pouvoir faire de la méta-programmation, si mes "définitions théoriques" sont correctes

[PhilIvey]

forcément si chacun peut définir comme il le souhaite les notions qui l'arrangent

en C#, la "reflexion" est surtout limitée à l'introspection non ?
hors, il faut aussi intercession de SmallTalk pour réellement pouvoir faire de la méta-programmation, si mes "définitions théoriques" sont correctes

Il existe d'autres formes de metaprogrammation , que le template metaprogramming du c++ ( statique et compile-time)!!!

Tu as bien sur de l'introspection, mais tu peux ajouter des champs,propriétés, instancier des types génériques, des fonctions génériques, filtrer des types....

[gorgonite]

Il existe d'autres formes de metaprogrammation , que le template metaprogramming du c++ ( statique et compile-time)!!!

ça fait assez peur de voir que tu ne m'as pas lu...

Tu as bien sur de l'introspection, mais tu peux ajouter des champs,propriétés, instancier des types génériques, des fonctions génériques, filtrer des types....

montres-moi en quoi C# est capable d'une intercession proche de SmallTalk ou Scheme, histoire que je vois ce que tu mets derrière la possibilité réelle de faire de la métaprogrammation en C#

tu parles d'une utilisation poussée du DLR ?

[Emmanuel Deloget]

montres-moi en quoi C# est capable d'une intercession proche de SmallTalk ou Scheme, histoire que je vois ce que tu mets derrière la possibilité réelle de faire de la métaprogrammation en C#

tu parles d'une utilisation poussée du DLR ?

Moi et la terminologie C#, ça fait 2. C'est quoi, DLR ?

Indépendamment, je pense qu'il parle surtout de la possibilité de caractériser et/ou définir du code au runtime, ce qui est possible dans une certaine mesure en C# (et en java) grâce a la réflexion. Lambda et réflexion sont capable de grandes chose .

On est effectivement loin du mécanisme des templates du C++, mais ça reste de la métaprog (puisque le principe de la métaprog, c'est le fait d'écrire du code qui va générer du code).

[oodini]

forcément si chacun peut définir comme il le souhaite les notions qui l'arrangent

en C#, la "reflexion" est surtout limitée à l'introspection non ?

Apparemment, Wikipedia classe bien la réflexion dans les techniques de métaprogrammation (voir arborescence à droite) :

http://en.wikipedia.org/wiki/Reflect...ter_science%29

[Niark13]

Moi et la terminologie C#, ça fait 2. C'est quoi, DLR ?

Dynamic Language Runtime, la couche d'interopérabilité avec les langages dynamiques rajoutée dans .Net 4.0 : http://fr.wikipedia.org/wiki/Dynamic_Language_Runtime

[gorgonite]

Apparemment, Wikipedia classe bien la réflexion dans les techniques de métaprogrammation (voir arborescence à droite) :

http://en.wikipedia.org/wiki/Reflect...ter_science%29

déjà wikipedia n'est pas une source toujours fiable (mais il ne tient qu'à nous de l'améliorer ^^)

ensuite, la reflexion contient l'introspection et l'intercession, et avec juste l'introspection on est loin de la meta-programmation ^^