Les compilos C++ se sont beaucoup améliorés, suite à l’arrivée de Clang (LLVM). Les possibilités offertes par LLVM sont impressionnantes, on commence à voir pas mal d’outils source-to-source grâce à ça (autrement dit, du “vrai” refactoring basé sur l’AST de ton programme, avant ou après les étapes d’optimisation). Clang permet même d’intégrer de l’autocomplétion contextuelle dans emacs maintenant, c’est dire…
Et franchement, à peine deux ans pour avoir 2 compilateurs sur les 3 gros (Clang, GCC, reste plus que MSVC à la traîne) qui respectent le nouveau standard C++11 c’est du jamais vu. J’ai bien peur que ta vision des compilateurs C++ ne soit un peu datée, suite aux énormes évolutions récentes (mais je te l’accorde, ça fait peu de temps que ça bouge autant). 
Les compilos C++ se sont beaucoup améliorés, suite à l’arrivée de Clang (LLVM). Les possibilités offertes par LLVM sont impressionnantes, on commence à voir pas mal d’outils source-to-source grâce à ça (autrement dit, du “vrai” refactoring basé sur l’AST de ton programme, avant ou après les étapes d’optimisation). Clang permet même d’intégrer de l’autocomplétion contextuelle dans emacs maintenant, c’est dire…
Et franchement, à peine deux ans pour avoir 2 compilateurs sur les 3 gros (Clang, GCC, reste plus que MSVC à la traîne) qui respectent le nouveau standard C++11 c’est du jamais vu. J’ai bien peur que ta vision des compilateurs C++ ne soit un peu datée, suite aux énormes évolutions récentes (mais je te l’accorde, ça fait peu de temps que ça bouge autant). [/quote]
gcc (et ses contributeurs) ont pris une grosse claque (bien méritée à mon humble avis) de la part de llvm/clang. Ils ont arrêté de se reposer sur leurs lauriers et doivent maintenant faire face à un retard dommageable (logiciel non-modulaire (c’était une volonté de RMS…)). Qui fait qu’aujourd’hui les 2 principaux avantages de gcc c’est les optimisations et le nombre d’architecture cible. Mais llvm gagne du terrain (il est le compilateur par défaut du future FreeBSD 10 et la prochaine Debian marquera un grand pas dans son indépendance vis à vis de gcc).
clang-complete (je pense que c’est ce dont tu parle) est vraiment un grand pas en avant (et une belle rigolade pour moi qui vois des développeurs C/C++ passer de « ça sert à rien/c’est dangereux » à « c’est génial »… les trolls). Les messages d’erreurs deviennent en fin lisibles (oublier le ; à la fin de la déclaration d’une classe deviens simple à comprendre…). Je ne sais pas ce qu’il en est de la métaprogrammation, je n’ai pas poussé un compilo là dessus depuis longtemps.
Pour ce qui est du temps extraordinairement court pour supporter la nouvelle norme, c’est tout de même à relativiser. Le commité à choisi de retirer des fonctionnalité justement pour simplifier la vie de ceux qui écrivent les compilateurs (au revoir les concepts) et essaie d’ajouter peu de choses mais plus régulièrement. D’ailleurs heureusement qu’ils n’ont mis que 2 ans parce que la prochaine norme arrive l’an prochain (en.wikipedia.org/wiki/C%2B%2B14) et celle d’après en 2017. Tout ça est inspiré du rythme des langages dynamiques tel que python ou ruby.
[quote=“MisterFreez”]clang-complete (je pense que c’est ce dont tu parle) est vraiment un grand pas en avant (et une belle rigolade pour moi qui vois des développeurs C/C++ passer de « ça sert à rien/c’est dangereux » à « c’est génial »… les trolls). Les messages d’erreurs deviennent en fin lisibles (oublier le ; à la fin de la déclaration d’une classe deviens simple à comprendre…). Je ne sais pas ce qu’il en est de la métaprogrammation, je n’ai pas poussé un compilo là dessus depuis longtemps.
Pour ce qui est du temps extraordinairement court pour supporter la nouvelle norme, c’est tout de même à relativiser. Le commité à choisi de retirer des fonctionnalité justement pour simplifier la vie de ceux qui écrivent les compilateurs (au revoir les concepts) et essaie d’ajouter peu de choses mais plus régulièrement. D’ailleurs heureusement qu’ils n’ont mis que 2 ans parce que la prochaine norme arrive l’an prochain (en.wikipedia.org/wiki/C%2B%2B14) et celle d’après en 2017. Tout ça est inspiré du rythme des langages dynamiques tel que python ou ruby.[/quote]
Faudrait du’on ouvre carrément un nouveau fil pour en discuter, il y a tellement à dire…
Les concepts étaient pourris à la base, ils ne savaient pas quoi en faire. Donc forcément ça n’a jamais vu le jour, je pense pas qu’ils aient été jusqu’à se demander si c’était implémentable, il y avait trop de défauts en amont*.
(*) La meilleure preuve à mon avis, c’est que même pour C++14 ils ont complètement repensé la proposition originale, et se sont rabattus sur des “concepts lite” qui n’ont que peu à voir avec ce qui était prévu au départ. Pourquoi ? Tout simplement parce que la proposition originale était mal pensée (y’a qu’à la décortiquer pour se rendre compte qu’elle était imbitable).
Pour la question des deux ans, faut quand même voir que C++11 est une putain de révolution pour le langage, ça apporte un sacré tas de nouveaux concepts. Perso j’ai commencé à migrer du code C++03 en C++11 et le résultat moyen c’est genre 50% de lignes en moins sur les parties “symptomatiques”, et 10 à 20% de performances de manière générale (quasiment tout grâce aux move semantics). Vu que je connais quand même assez bien le langage, je peux te garantir que deux ans pour implémenter autant de nouveautés c’est un boulot hallucinant. Mais évidemment Clang est le principal “fautif” car ils ont une architecture super souple, ce qui pousse GCC dans ses retranchements et l’oblige à se bouger le derche. 
[quote=“syam”][quote=“MisterFreez”]clang-complete (je pense que c’est ce dont tu parle) est vraiment un grand pas en avant (et une belle rigolade pour moi qui vois des développeurs C/C++ passer de « ça sert à rien/c’est dangereux » à « c’est génial »… les trolls). Les messages d’erreurs deviennent en fin lisibles (oublier le ; à la fin de la déclaration d’une classe deviens simple à comprendre…). Je ne sais pas ce qu’il en est de la métaprogrammation, je n’ai pas poussé un compilo là dessus depuis longtemps.
Pour ce qui est du temps extraordinairement court pour supporter la nouvelle norme, c’est tout de même à relativiser. Le commité à choisi de retirer des fonctionnalité justement pour simplifier la vie de ceux qui écrivent les compilateurs (au revoir les concepts) et essaie d’ajouter peu de choses mais plus régulièrement. D’ailleurs heureusement qu’ils n’ont mis que 2 ans parce que la prochaine norme arrive l’an prochain (en.wikipedia.org/wiki/C%2B%2B14) et celle d’après en 2017. Tout ça est inspiré du rythme des langages dynamiques tel que python ou ruby.[/quote]
Faudrait du’on ouvre carrément un nouveau fil pour en discuter, il y a tellement à dire…
Les concepts étaient pourris à la base, ils ne savaient pas quoi en faire. Donc forcément ça n’a jamais vu le jour, je pense pas qu’ils aient été jusqu’à se demander si c’était implémentable, il y avait trop de défauts en amont*.
(*) La meilleure preuve à mon avis, c’est que même pour C++14 ils ont complètement repensé la proposition originale, et se sont rabattus sur des “concepts lite” qui n’ont que peu à voir avec ce qui était prévu au départ. Pourquoi ? Tout simplement parce que la proposition originale était mal pensée (y’a qu’à la décortiquer pour se rendre compte qu’elle était imbitable).[/quote]
Chez gcc (je ne sais pas pour clang), ils ont bossé deuss pendant quelques années jusqu’à l’abandon officiel de la fonctionnalité.
La page des concepts de wikipedia indique que ça n’a pas l’air vraiment abandonné, peut être que la forme ne conviens pas, mais le comité ne compte pas en rester là : en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 (c’est sourcé).
Oui puis ils ont pas attendu 2011 pour commencer à implémenter tout cela, comme ils sont déjà entrain d’implémenter C++14 (je parle du langage pour la bibliothèque standard une partie non négligeable viens directement de boost (et ce seras pareil pour C++14).
Nan je ne peux pas m’y rendre à cause du boulot.
À mon avis c’est en partie du à la syntaxe des références trop invisible, il y a des fois où l’on ne voit plus si on manipule une référence ou non. Parce que d’un point de vu purement technique ce qui est déplacé pourrait ne pas l’être 
(à moins que tu connaisse un cas qui ne me viens pas à l’esprit 
).
Le gros à mon avis à implémenter c’est l’inférence de type (c’est pas toujours trivial) et les variadics templates qui demandent un gros travail au niveau du compilateur et qui fait partie des choses les plus sophistiquées du C++ (je ne doute pas que tu le sais déjà mais c’est de la génération de code). Il y a aussi les travaux sur les threads mais je ne sais pas qu’elle est la complexité à implémenter ce truc.
Justement j’y vais “à cause” du boulot. Faut bien que toutes ces heures “de formation” servent à quelque chose…
Accessoirement, quand je t’envoie un MP c’est pas pour que tu me répondes en public. (ça regarde personne où je vais quand…) Mais je râle juste pour le principe t’inquiète, c’est juste que je suis sensible au niveau des “traces” sur internet. 
En vrai c’est pas terriblement important non plus, no hard feelings.
À mon avis c’est en partie du à la syntaxe des références trop invisible, il y a des fois où l’on ne voit plus si on manipule une référence ou non. Parce que d’un point de vu purement technique ce qui est déplacé pourrait ne pas l’être (à moins que tu connaisse un cas qui ne me viens pas à l’esprit ).[/quote]
Justement, le nouveau standard amène d’énormes nouveautés de ce côté. Là où avant tu ne pouvais que prendre par const ref et ensuite copier, maintenant tu prends direct par valeur et tu déplaces. La décision de copier ou de déplacer retombe sur l’appelant, qui sait mieux que toi si sa variable va lui être utile ou pas plus tard.
Voir l’article “Want speed? Pass by value” qui résume bien ce nouvel état de faits en C++11 (bien que le seul titre semble aller à l’encontre de toutes les “bonnes pratiques” qu’on connaissait… en C++03…).
L’inférence de types, franchement, c’est bidon IMHO : le compilateur savait déjà le type des (rvalue) expressions, donc le coup du auto c’est un peu bidon. Le seul truc un poil complexe c’est peut-être la déduction des types de retour des fonctions. Et encore…
Variadic templates : OK ça a l’air compliqué, je vais pas faire le malin à ce niveau, ils ont dû sacrément en chier à implémenter ça. 
Les threads, c’est juste la formalisation théorique de ce que tout le monde utilisait déjà en pratique. Rien de nouveau, donc, juste du blabla sur un bout de papier.
Oups 
je pensais que tu t’étais trompé de bouton (comme ça m’est déjà arrivé). J’en suis navré (tu aurais pu supprimé mon message).
Je lis ça dans le train demain
L’inférence de types, franchement, c’est bidon IMHO : le compilateur savait déjà le type des (rvalue) expressions, donc le coup du auto c’est un peu bidon. Le seul truc un poil complexe c’est peut-être la déduction des types de retour des fonctions. Et encore…[/quote]
À l’essai, c’est surtout que c’est très limité (à des années de ce que fais n’importe quel langage fonctionnel). La prochaine norme apportera la possibilité de le mettre en retour de fonction, mais ça restera limité.
Pas pour si peu, ça arrive à tout le monde et y’a pas mort d’homme non plus. Par contre maintenant que tu le dis, je viens de me souvenir que je suis quand même modo donc j’ai édité ton message pour supprimer la partie “perso”. Non mais. 