Discussion :

[JolyLoic]

Sur un point de cette amplitude, peut-être une simple issue peut-elle aussi faire l'affaire ? Mais en tout cas, j'ai tenté de sonder les gens, pour cette version, ça a l'air d'être un peu tard.

[Klaim]

Je pensais plutot a la version suivante et aussi je pensais que toutes les propositions étaient revues au moins une fois dans la mailing list privée par exemple.


Sinon, il me semble qu'il y a un racourcis à base de stl pour avoir la même chose non (un std::vector<string> avec les différents arguments séparés)? Je cherche où j'ai lu un exemple en une ligne, je ne me souviens plus quel algorithme était utilisé.

[Arzar]

Sinon, il me semble qu'il y a un racourcis à base de stl pour avoir la même chose non (un std::vector<string> avec les différents arguments séparés)? Je cherche où j'ai lu un exemple en une ligne, je ne me souviens plus quel algorithme était utilisé.

Errmm, la page 2 de ce même thread

[Klaim]

Effectivement, j'avais zappé le bout de code

[Goten]

J'up le topic car je parcourais le draft hier, et je suis tombé sur vector<bool>. J'étais persuadé d'avoir lu quelque part qu'il était question de le faire disparaître dans la nouvelle norme, j'ai rếvé ou il en a bien été question? (Loic peut être?)

[Klaim]

Je ne me souviens pas qu'ils voulaient le virer, par contre auto_ptr<> est deprecated il me semble.

[Klaim]

Est-ce que quelqu'un ici a pu lire ce bouquin en entier? (Scott Meyer a propos de C++0x)

http://www.artima.com/shop/overview_of_the_new_cpp

Histoire d'avoir une idée de l'interet.

[Aleph69]

Bonjour,

Aussi paradoxal que cela puisse paraître, aujourd'hui beaucoup d'entreprise ont encore visual 6 (alors que plus supporté par microsoft) car il y a un risque levé sur une éventuelle migration. Nous n'avons pas tous la chance d'avoir le temps d'un labo de recherche ou d'un nouveau projet from scratch.

J'ai une question à ce propos.
Bon, elle n'a peut-être pas de sens alors soyez indulgents!

J'ai travaillé dans une de ces entreprises qui continuent à utiliser Visual 6.
En fait, dans ce cas particulier, la principale raison pour laquelle on ne migrait pas était que les temps de compilation avaient explosé entre la version 6 et les versions d'après (ce n'est peut-être plus vrai maintenant d'ailleurs?).

Est-ce que le changement de norme peut avoir un impact négatif ou positif sur les temps de compilation (indépendamment du compilo)?

[koala01]

Bonjour,



J'ai une question à ce propos.
Bon, elle n'a peut-être pas de sens alors soyez indulgents!

J'ai travaillé dans une de ces entreprises qui continuent à utiliser Visual 6.
En fait, dans ce cas particulier, la principale raison pour laquelle on ne migrait pas était que les temps de compilation avaient explosé entre la version 6 et les versions d'après (ce n'est peut-être plus vrai maintenant d'ailleurs?).

Est-ce que le changement de norme peut avoir un impact négatif ou positif sur les temps de compilation (indépendamment du compilo)?

A ma connaissance non...

D'autant plus que tous les compilateurs actuels supportent encore l'ancienne norme par défaut, et seuls les plus récents (VS2008 (s'il le fait) ou VS2010, pour la série visual) n'utilisent la nouvelle norme que lorsque l'on indique clairement que cela doit être le cas.

Comment pourrait-il en être autrement, alors que cette nouvelle norme n'est pas encore officiellement sortie

Les règles de parsing sont restées exactement identiques pour tout ce qui a trait à l'ancienne norme dans la nouvelle.

Il y a eu quelques ajouts (lambda, big four delete et default), mais il n'y a pas vraiment de raison pour que cela ralentisse la compilation si tu n'active pas le support de la nouvelle norme

Mais bon, tu sais sans doute comme moi que les programmes grossissent de plus en plus, et il est vrai que le seul fait d'utiliser VS2008 sur un Athlon 1700 XP tient déjà du miracle ... j'irais plutôt voir du coté de la machine sur lequel le compilo tourne

[JolyLoic]

Il y a des choses qui peuvent avoir un impact (et même parfois un impact positif ) et des choses qui auraient pu en avoir un... Par contre, il faut généralement mettre à jour le code source, ou au minimum le code source des bibliothèques externes utilisées.

Par exemple :
Les variadic templates doivent permettre de supprimer les alternatives actuelles à base de macro générant les versions à 1, 2, 3... n arguments templates. Je crois me souvenir d'un impact positif notable sur la compilation par exemple de boost.

Export a pu avoir un impact positif sur les temps de compilation (ou de recompilation), même s'il est désormais mort.

Si on avait eu des modules, à la place du système archaïque de #include utilisé actuellement, les performances de compilation auraient pu faire un bon en avant énorme (c'était une des motivations des modules). Peut-être en C++2x ?..

[Goten]

Les variadic templates doivent permettre de supprimer les alternatives actuelles à base de macro générant les versions à 1, 2, 3... n arguments templates. Je crois me souvenir d'un impact positif notable sur la compilation par exemple de boost.

Pas sur, les variadiques templates entrainent beaucoup trop d'instanciation template (et le PP est plutôt rapide). Eric Niebler avait donné des chiffres (concernant Proto?) et c'était pas glorieux...

[JolyLoic]

De mémoire, ce n'était pas tant le PP qui prenait du temps, mais le fait que le jeu de fonctions candidates à la surcharge explosait. Mais je n'ai ni références ni chiffres en tête.

[Aleph69]

Merci pour vos réponses.
D'après ce papier, ça a l'air de réduire pas mal les temps de compilation dans certains cas :
http://citeseerx.ist.psu.edu/viewdoc...10.1.1.103.144
C'est impressionnant!
Bienvenue aux variadic templates!

[Alp]

De mémoire, ce n'était pas tant le PP qui prenait du temps, mais le fait que le jeu de fonctions candidates à la surcharge explosait. Mais je n'ai ni références ni chiffres en tête.

C'est ça.

Et effectivement, les templates variadiques permettent de gagner un peu de temps. Le compilo *sait* qu'on fait du variadique, on est plus obligé de générer (parfois inductivement en plus!) les n versions. Le compilo détecte le nombre de paramètres, instancie l'entité qui va bien dans son graphe sémantique, et c'est réglé.

C'est le genre de choses qui va pas mal aider sur les projets qui utilisent boost (ne serait-ce que boost.variant par exemple!).

[Goten]

J'attends les chiffres perso, je suis pas convaincu. Joel si tu passes par là, t'étais pas là quand on en a discuté ?

[Invité]

http://www.drdobbs.com/blog/archives...ilation_s.html

The 7 phases of translation [1]. Although some of these can be combined, there are still at least 3 passes over the source text. At least I never was able to figure out how to reduce it below 3. A fast language design would have just one. C++0x exacerbates this by requiring that trigraph and \ line splicing be unwindable to support raw string literals [2].

[guillaume07]

mais au faite pourquoi la nouvelle norme n'est pas encore officiellement sortie, alors que le "final draft" a été voté, c'est quoi la différence ?

[gl]

mais au faite pourquoi la nouvelle norme n'est pas encore officiellement sortie, alors que le "final draft" a été voté, c'est quoi la différence ?

Jean Marc l'explique dans le premier message de ce sujet :

La suite des opérations: jusque début juillet pour faire parvenir les commentaires officiels.

3 réunions pour agir sur ces commentaires (août 2010, novembre 2010, mars 2011). La dernière peut décider soit de repartir pour un FCD (et donc des commentaires dont il faut tenir compte) soit pour un FDIS (ou il faut dire oui ou non).

[Klaim]

Ca bouge a mort en ce moment coté C++0x, plein de problemes à régler! (via le blog d'herb sutter)

C'est la première fois que je suis ce genre de spécifications de près, alors j'ai l'impression que globalement ça se passe mal.

Ais-je tord? Ou je suis juste pessimiste?

[Goten]

C'est le blog d'Anthony williams (MR thread ) et non moi je vois rien d'alarmant..