Validité de C++11 en environnement pro

Version imprimable

19/02/2013, 10h44
jblecanard

Validité de C++11 en environnement pro

Hello tous

Petit débat sur C++11, pas tant sur les fonctionnalités, mais plutôt sur la solidité des implémentations actuelles.

Utilisez-vous déjà du code compilé en C++11 en prod ? Avec gcc, clang, vc ? Que savez-vous de la stabilité des implémentations ? Ou trouver des infos fiables et régulièrement mises à jour sur ce point ?

Pour ma part, je cherche à évaluer tout ça avant une éventuelle utilisation dans un environnement ou les services critiques (côté serveur) sont en C++. Pour une appli cliente, ce serait moins risqué mais dans mon cas il faut être très prudent. Merci d'avance pour vos contributions :).
19/02/2013, 11h04
Ehonn

La question porte plus sur les compilateurs et la confiance qu'on accorde aux nouvelles versions (?)

J'utilise C++11 tout les jours mais les programmes ne sont pas pour des clients. Je n'ai jamais rencontré de souci :) et l'utilisation de C++11 permet de simplifier les programmes et les rendre plus portables, deux qualités qu'on recherche en développement :)

L'environnement reste relativement simple, il suffit d'avoir un compilateur à jour et GCC et Clang sont libres, multi-plateformes et gratuits (et utilisés en entreprise (au moins GCC)).

Pour le support de C++11 dans GCC et Clang :
http://gcc.gnu.org/projects/cxx0x.html
http://gcc.gnu.org/projects/cxx0x.html

Pour la "fiabilité", le mieux est de tester...
Sinon, il y a toujours les rapports de bug des différents projets. Si on juge uniquement le nombre de bugs, c'est une information un peu délicate : cela peut tout simplement signifier que le projet est vivant. Il faudrait prendre en compte beaucoup de paramètres comme le nombre de bugs, d'utilisateur, la réactivité des développeurs, ...
19/02/2013, 14h42
Klaim

Citation:

Envoyé par jblecanard

Utilisez-vous déjà du code compilé en C++11 en prod ? Avec gcc, clang, vc ?

Alors,
- actuellement je suis a mon compte, j'utilise C++11 mais je me limite aux fonctionalites qui sont commune aux trois compilateurs, donc a ce que VC11 fournis;
- dans mon precedant boulot (il y a presque un an), je bossais pour l'iPhone, j'avais carte blanche sur l'implementation donc j'utilisai C++11 de la version de Clang fournie par Apple (qui n'est pas la meme que celle publiee avec LLVM) - yavait pas mal de fonctionalites que j'ai exploite a mort, mais cetait du code trop rapidement develope donc pas fait pour etre maintenu;
- dans le boulot precedant, on utilisait GCC4.4 pour un projet super monolithique et mega sur-template (genre qui compile en 45 minutes mais produit un executable de 2 mega...) et on a fait pas mal d'ameliorations en exploitant certaines features de C++11 deja implemente dans cette version. Par contre je recommande plutot un compilo recent hein;

Citation:

Que savez-vous de la stabilité des implémentations ?

VS2010 (VC10) a une implementation douteuse des lambda.
A part ca j'ai pas eu de probleme...

Citation:

Ou trouver des infos fiables et régulièrement mises à jour sur ce point ?

http://isocpp.org

Citation:

Pour ma part, je cherche à évaluer tout ça avant une éventuelle utilisation dans un environnement ou les services critiques (côté serveur) sont en C++. Pour une appli cliente, ce serait moins risqué mais dans mon cas il faut être très prudent. Merci d'avance pour vos contributions :).

Conseil:
Si tu utilises un compilo recent, active C++11 sans tarder. Code normalement, utilise les features du C++11 qui te son dispo, la ou ca aide, mais ne te force pas non plus, ca reste juste des outils.

Generalement le code genere n'aura aucun souci. Les deux trucs qui peuvent etre problematiques:

- le manque de features supportees par le compilateurs (VS2012 manque cruellement des variadic templates... - et me parlez pas du CTP, c'est completement inutile en production);
- rarement, une implementation d'une feature qui t'empeche de l'utiliser. Mais dans ce cas, tu peux faire la meme chose autrement.

Donc vasy, t'as strictement rien a perdre, et au pire, rien a gagner. Note aussi qu'un compilo supportant certaines features du C++11 qui sont plus ou moins invisibles (r-value reference par example) vont avoir plus d'opportunites d'optimisation juste en recompilant ton code C++03. Note aussi que c'est surtout vrai si tu utilises la bibliotheque standard.
19/02/2013, 16h21
jblecanard

Merci pour cette réponse riche.

Citation:

Envoyé par Klaim

Note aussi qu'un compilo supportant certaines features du C++11 qui sont plus ou moins invisibles (r-value reference par example) vont avoir plus d'opportunites d'optimisation juste en recompilant ton code C++03. Note aussi que c'est surtout vrai si tu utilises la bibliotheque standard.

C'est le but, j'utilise beaucoup la STL :)

Citation:

Envoyé par Klaim

Generalement le code genere n'aura aucun souci.

C'est ma seule source de crainte en fait !
19/02/2013, 16h27
Klaim

Citation:

Envoyé par jblecanard

C'est ma seule source de crainte en fait !

Alors oublie tes soucis! La partie qui genere le code et la partie qui gere le language sont distinct sur la plupart des compilateur (on sait pas pour VC mais c'est peu probable que ce soit autrement).

Il y a tres peu de features impactant la partie generation de code, et quand c'est le cas, les compilateurs ont verifie et donne leur aprobation avant le vote du standard.
19/02/2013, 18h49
jblecanard

Citation:

Envoyé par Klaim

Si tu utilises un compilo recent, active C++11 sans tarder.

C'est là que ça coince, pour l'instant j'utilise la version 4.1.3 (ce n'est pas de mon fait). Y a-t-il un gros risque en général à passer à une version 4.7, sachant que je vise une architecture x64 tout ce qu'il y a de plus standard ?
19/02/2013, 22h57
Klaim

Citation:

Envoyé par jblecanard

C'est là que ça coince, pour l'instant j'utilise la version 4.1.3 (ce n'est pas de mon fait). Y a-t-il un gros risque en général à passer à une version 4.7, sachant que je vise une architecture x64 tout ce qu'il y a de plus standard ?

Si ton code est standard, non aucun risque. Ah si, si t'utilises le mot cle auto, ben faut pas.

Sinon ya ptete des differences parceque les versions <4.4 etaient pas vraiment top, mais ca ne fera que te forcer a corriger des trucs qui sont incorrects.

Je veux dire, t'as rien a perdre sauf si tu utilises quelque chose qui n'existe pas dans les versions suivante du compilo, auquel cas ca veut deja dire que tu utilises quelque chose de specifique au compilo, ce qui est en soit une mauvaise idee.

Donc go for it.

Au pire, clone ton repository de code, et trouve le moyen de le compiler avec un compilo recent. Corrige jusqu'a ce que ca compile, ca te donnera une idee de l'effort a fournir pour la transition.
20/02/2013, 00h41
jblecanard

Citation:

Envoyé par Klaim

Ah si, si t'utilises le mot cle auto, ben faut pas.

Tu peux développer ? Y a-t-il des pièges à éviter autres que les conversions de types automatiques hasardeuses avec auto ?

Salut,

Citation:

Envoyé par jblecanard

Tu peux développer ? Y a-t-il des pièges à éviter autres que les conversions de types automatiques hasardeuses avec auto ?

En C++03, le mot clé auto était un "storage classe specifier", c'est à dire un mot clé qui permettait d'indiquer explicitement qu'une variable avait une durée de vie automatique (s'étendant de sa déclaration à l'accolade fermante qui la contenait).

C'est, en fait, le comportement par défaut de toute variable ;)

Comme on s'est rendu compte à l'usage que ce mot clé n'était pour ainsi dire jamais utilisé, on a décidé (comprends: les membres du comité de normalisation on décidé, car je n'ai rien à voir là dedans :D) de supprimer cet usage et de le remplacer par quelque chose de plus intéressant et sans doute de beaucoup plus utile: le fait d'indiquer au compilateur qu'il doit essayer de déterminer de lui-même le type de la variable en fonction du contexte.

L'énorme avantage est qu'il n'est plus forcément utile d'écrire un code proche de
Code:

1 2 std::map<std::complex<double>, std::string>::const_iterator it = lamap.find(/*...*/ );
car on peut se contenter d'un

Code:

auto it = lamap.find(/*...*/);

qui fera en sorte que le type de it sera automatiquement déduit du type de retour de find (un const_iterator ou un iterator, en fonction du contexte, en l'occurrence)

Note cependant que l'on peut parfois être surpris du type déduit, avec un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 std::map<Cle, Valeur> lamap; /* le remplicage que je passe */ for(auto it : lamap) //"range based loop" qui parcourt l'ensemble des éléments { // it n'est pas un std::map<Cle, Valeur>::const_iteator, // ni même un std::map<Cle, Valeur>::iterator // mais sans doute un std::pair<Cle, Valeur> // (voir une référence (éventuellement constante) sur une std::pair<Clé, Valeur> // si on a écrit for(auto /* const &*/ it : lamap) ;) ) }

20/02/2013, 08h56
jblecanard

Citation:

Envoyé par koala01

Salut,En C++03, le mot clé auto était un "storage classe specifier", c'est à dire un mot clé qui permettait d'indiquer explicitement qu'une variable avait une durée de vie automatique (s'étendant de sa déclaration à l'accolade fermante qui la contenait).

Donc le conseil était bien de ne pas utiliser auto version C++03 ! Ca m'aurait ennuyé de me voir conseiller de ne pas utiliser le auto de C++11 :mrgreen: ouf
20/02/2013, 10h56
Klaim

Oui desole si c'etait pas clair. Merci koala01 :ccool:
20/02/2013, 11h02
Arzar

Deux exemples qui éclairent assez bien à mon sens les diverses problématiques de migration :

1) LLVM/Clang

Il y a eu récemment un thread sur la mailing list pour discuter d'une possible migration vers C++11. Ce thread résume bien les difficultés rencontrées dans un cas comme llvm avec un besoin assez fort de rétro-compatibilité + multi-plateforme, multi-architecture.

http://lists.cs.uiuc.edu/pipermail/l...ry/057787.html

Après discussion la conclusion s'est imposée d'elle même : impossible de migrer vers C++11. En effet L'architecte principal Chris Lattner a posé comme condition que LLVM soit compilable sur une base de GCC 4.4 et Visual Studio 2010. (ce qui correspond à des compilos quand même assez récent, 2/3 ans maximum, c'est donc loin d'être un choix conservatif). Après analyse il est apparu que l'intersection des features C++11 disponible sur cette base est tellement ridicule réduite que les efforts pour migrer + la perte de compatibilité avec des compilos plus vieux n'en valent pas la chandelle.

2) Facebook

(Infos glanées en lisant la doc de Folly, la biblio open source de Facebook qui fournit des briques de base pour tous les autres projets chez Facebook)

Je suppose que c'est intéressant pour toi jblecanard, vu qu'on tombe pile dans un cas ou "des services critiques (côté serveur) sont en C++". :mrgreen:

Contrairement à llvm, Facebook ne cible qu'un seul compilateur et une seule architecture : GCC sur x64. Ils n'ont pas l'air d'avoir de complexe à utiliser des compilos très récents et à upgrader régulièrement. Ils étaient sur GCC 4.6 il y a quelques mois et maintenant sur GCC 4.7. Le mode -std=c++11 est activé. Ils utilisent d'ailleurs assez fréquemment dans folly des features du C++11, en particulier variadic template, type_trait et atomic.
20/02/2013, 11h18
jblecanard

Citation:

Envoyé par Arzar

Je suppose que c'est intéressant pour toi jblecanard, vu qu'on tombe pile dans un cas ou "des services critiques (côté serveur) sont en C++". :mrgreen:

Contrairement à llvm, Facebook ne cible qu'un seul compilateur et une seule architecture : GCC sur x64. Ils n'ont pas l'air d'avoir de complexe à utiliser des compilos très récents à upgrader régulièrement. Ils étaient sur GCC 4.6 il y a quelques mois et maintenant sur GCC 4.7. Le mode -std=c++11 est activé.

C'est une info en or, on tombe pile dans mon cas !