Améliorations du compilateur VC++ pour les normes C++11, C++14, C99

Version imprimable

1 pièce(s) jointe(s)

Améliorations du compilateur VC++ pour les normes C++11, C++14, C99
15 nouvelles fonctionnalités supportées par le compilateur

Alors qu'ils sont en retard par rapport à leurs concurrents que sont GCC et Clang, la dernière version de VC++ apporte le support de plusieurs fonctionnalités sur les deux langages C et C++.

http://www.developpez.net/forums/att...1&d=1384623620

Au menu du C++ :

le mot clé explicit qui permet d'éviter les conversions implicites non désirées ;
les chaînes de caractères litérales brutes ;
les arguments par défaut pour les fonction templates ;
les constructeurs délégués ;
l'initialisation uniforme avec les accolades {} ;
l'initialisation lors de la déclaration des attributs membres non statiques ;
les spécifications = default et = delete ;
les alias via using ;
les variadics templates ;
bonus C++14 – pour une fois qu'ils sont en avance saluons-les ! – les foncteurs en diamant.

Pour le C99 — ce qui soulève tout de même un petit sourire en coin quand on sait que le langage C en est à sa norme C11 — on est tout de même ravi de voir enfin des fonctionnalités qui nous semblent désormais faire partie des bases même du C :
la déclaration des variables dans les blocs, ce qui permet de ne plus être forcé de les déclarer au début de la fonction ;
le type _Bool et sa macro bool dont il n'est plus utile de rappeler l'utilité tant elle est commune ;
les littéraux composés qui permettent d'initialiser une structure avec une série d'attributs entre accolades ;
les initialisateurs nommés qui permettent d'initialiser des attributs particuliers d'une structure en spécifiant leurs noms (n'existe pas en C++):
Code:

1 2 3 4 5 6 7 8 9 10 struct C { int attr_a; int attr_b; int attr_c; }; struct C my_c = {.attr_a = 33, .attr_c = 26};//attr_b = 0 int array[][2] = {[0][0] = 1, [1][1] = 1};//2x2, autres valeurs à 0
Source : ISO C++ Additions in Visual C++

Et vous,
:fleche: Utilisez-vous VC++ ?
:fleche: Pensez-vous qu'il va pouvoir rattraper ses concurrents pour C++14 ?
:fleche: Pensez-vous qu'il s'agisse d'un bon compilateur pour développer en C ?

17/11/2013, 07h26
Neckara

Bonjour,

Personnellement, je ne développe pas avec VC++ et je ne pense pas que c'est un bon compilateur.

Déjà il suit les normes un peu comme cela lui chante. Rien ne nous garantit par exemple qu'il décidera d'implémenter le C++17 tout comme il refusait de supporter le C++11 jusqu'à maintenant.

Ensuite, VC++ et VS ne sont pas portables donc lorsqu'on doit développer pour plusieurs environnements, ce n'est pas très "pratique".
Alors qu'à côté, on a des compilateurs et des IDE qui sont, eux, portables.

Après, il me semble aussi que VC++ introduit quelques fonctionnalités qui ne sont pas dans la norme (un peu comme gcc avec -std=gnu99 par exemple) or ça et le fait que VC++ ne soit pas portable introduit un risque supplémentaire de produire un code non-portable.

D'ailleurs me semble même que VC++ produit des erreurs lors de cast vers un typedef alors qu'il me semble bien que même en C89 c'est légal :koi:.

Et puis bon... Déjà même l'aide de microsoft nous conseille des choses qui ne sont pas standard et qui devrait provoquer un comportement indéfini comme fflush(stdin);.
17/11/2013, 12h57
JolyLoic

Citation:

Envoyé par Neckara

Personnellement, je ne développe pas avec VC++ et je ne pense pas que c'est un bon compilateur.

Déjà il suit les normes un peu comme cela lui chante. Rien ne nous garantit par exemple qu'il décidera d'implémenter le C++17 tout comme il refusait de supporter le C++11 jusqu'à maintenant.

Je ne crois pas que le retard sur C++11 soit lié à un quelconque refus, mais plus à une bête question de ressources. Dès le début, Microsoft a annoncé sa volonté d’implémenter tout le standard. Le seul refus que j'ai entendu de la parte de Microsoft était l'implémentation du mot clef export de C++98, que ni gcc ni clang ne supportent non plus, et qui a depuis été ôté de la norme (ce que d'un certain point de vue, je trouve dommage, il y a un problème que ce mot clef essayais de résoudre, très imparfaitement certes, mais ce problème existe toujours).

Citation:

Envoyé par Neckara

Ensuite, VC++ et VS ne sont pas portables donc lorsqu'on doit développer pour plusieurs environnements, ce n'est pas très "pratique".
Alors qu'à côté, on a des compilateurs et des IDE qui sont, eux, portables.

Après, il me semble aussi que VC++ introduit quelques fonctionnalités qui ne sont pas dans la norme (un peu comme gcc avec -std=gnu99 par exemple) or ça et le fait que VC++ ne soit pas portable introduit un risque supplémentaire de produire un code non-portable.

C'est là aussi un problème que l'on peut retrouver avec n'importe quel compilateur. Même si on a désormais des compilateurs qui compilent toute la norme, on est loin d'en avoir qui ne font rien que la norme. Certains arrivent à s'en tirer grâce à des flags de compilation qui permettent de désactiver les extensions, Visual C++ a plus de mal de ce côté là, ne serait-ce que parce que certaines de ces extensions sont lourdement utilisées dans les header windows, ce qui fait que tout flag de ce type empêche de compiler la quasi totalité des programmes windows...
Après, un compilateur qui ne ferait que la norme stricto sensu ne serait probablement pas idéal non plus. Comment expérimenter des nouveautés dans la norme s'il n'y a pas moyen d'en tester des brouillons auprès de véritables utilisateurs ?

Pour moi, ce qui compte plus que le fait qu'une environnement de développement soit portable, c'est avant tout que le code que l'on écrit soit portable. Et il est hélas possible d'écrire du code non portable sans s'en rendre compte quel que soit le compilateur. Ne serait-ce que parce que les incompatibilités ne sont pas toutes liées au langage (et le fait que la convergence que l'on voit en terme de compilateur va diminuer cet aspect est une très bonne chose) mais aussi aux bibliothèques que l'on peut utiliser, et à la manière de les utiliser.

Citation:

Envoyé par Neckara

D'ailleurs me semble même que VC++ produit des erreurs lors de cast vers un typedef alors qu'il me semble bien que même en C89 c'est légal :koi:.

En lisant ton lien, on voit que c'est un problème qu'ils avaient avec visual C++5.0, qui date de 1997... Je suis persuadé qu'on peut trouver plein d'autres problèmes dans des compilateurs qui datent de cette époque (ou plus récents), quel que soit le compilateur

Citation:

Envoyé par Neckara

Et puis bon... Déjà même l'aide de microsoft nous conseille des choses qui ne sont pas standard et qui devrait provoquer un comportement indéfini comme fflush(stdin);.

Là, je suis d'accord, leur aide en ligne devrait à mon avis différencier plus clairement ce qui est standard de ce qui constitue une extension du langage.
17/11/2013, 13h13
JolyLoic

Citation:

Envoyé par germinolegrand

:fleche: Utilisez-vous VC++ ?

Oui. C'est le standard de fait sous windows. Il ne brille peut-être pas par son respect de la norme (même si je trouve qu'avec les additions récentes, il a suffisamment rattrapé son retard pour que ce dernier soit devenu une gêne et non plus un handicap), mais ce n'est pas là qu'est sa force. Sa force réside avant tout dans l'écosystème qu'il y a autour : Déjà l'environnement de développement pour lequel je n'ai pas vu d'équivalent, bien qu'en ayant essayé d'autres (après, mon habitude de celui-ci constitue certainement un biais, mais j'ai essayé d'être objectif. Et je n'ai pas non plus testé xcode. Peut-être arrive-t-il au niveau?). Ensuite toutes les bibliothèques disponibles (la plupart des bibliothèques open-source, et tout un tas de bibliothèques closed-source spécifiques windows). Et puis les outils de débug, perfs...

Citation:

Envoyé par germinolegrand

:fleche: Pensez-vous qu'il va pouvoir rattraper ses concurrents pour C++14 ?

Je l'espère (tout comme j'espère que ses concurents vont le rattraper sur les points où il est en avance). J'espère même qu'il sera en avance de phase sur certains TS qui ne seront pas partie de C++14 stricto sensu (je pense très fort aux concepts, et croise les doigts).

Citation:

Envoyé par germinolegrand

:fleche: Pensez-vous qu'il s'agisse d'un bon compilateur pour développer en C ?

Non. Ce n'est d'ailleurs pas leur objectif. Et ça ne me gêne pas particulièrement. Je peux voir de l'intérêt au C dans le monde de l'embarqué (principalement de part la petitesse du langage qui en rend une implémentation de bonne qualité aisée et peu coûteuse), mais quand on développe sous un vrai OS où des compilateurs C++ de qualité existent, je ne me vois pas développer en C. Le seul problème que pose alors le fait que Microsoft ait le même point de vue que moi est pour la récupération de bibliothèques existantes écrites en C.
17/11/2013, 13h46
Neckara

Citation:

Envoyé par JolyLoic

Je ne crois pas que le retard sur C++11 soit lié à un quelconque refus, mais plus à une bête question de ressources. Dès le début, Microsoft a annoncé sa volonté d’implémenter tout le standard.

Il me semble bien avoir lu une actualité il y a fort longtemps de cela disant que Microsoft n'implémenterait pas totalement le C++11. Mais je serais bien incapable de retrouver l'actualité pour voir exactement de quoi il était question.

Citation:

Pour moi, ce qui compte plus que le fait qu'une environnement de développement soit portable, c'est avant tout que le code que l'on écrit soit portable.

Même si le code écrit avec des extensions de gcc (par exemple) ne suit pas strictement la norme, le code n'en reste pas moins "portable" car il pourra être compilée pour toutes les plateforme grâce au fait que gcc soit lui-même portable.
Après, avoir un environnement de développement "portable" est, je pense, plus qu'utile lorsqu'on travaille en équipe.

Citation:

Et il est hélas possible d'écrire du code non portable sans s'en rendre compte quel que soit le compilateur. Ne serait-ce que parce que les incompatibilités ne sont pas toutes liées au langage (et le fait que la convergence que l'on voit en terme de compilateur va diminuer cet aspect est une très bonne chose) mais aussi aux bibliothèques que l'on peut utiliser, et à la manière de les utiliser.

Personnellement, quand j'utilise une fonction, je regarde son man et je vois tout de suite si elle est portable ou non.
Quand j'utilise une bibliothèque, je regarde sur leur site et je vois tout de suite si ce sera portable ou non.
Donc ne pas faire du code portable (à 2-3 rectifications près), c'est pour moi le faire exprès.

Citation:

mais quand on développe sous un vrai OS

Et depuis quand Windows est un vrai OS ? :koi: (désolé mais la perche était trop tentante)
17/11/2013, 14h25
JolyLoic

Citation:

Envoyé par Neckara

Il me semble bien avoir lu une actualité il y a fort longtemps de cela disant que Microsoft n'implémenterait pas totalement le C++11. Mais je serais bien incapable de retrouver l'actualité pour voir exactement de quoi il était question.

C11, pas C++11, ou alors je suis passé à côté...

Citation:

Envoyé par Neckara

Même si le code écrit avec des extensions de gcc (par exemple) ne suit pas strictement la norme, le code n'en reste pas moins "portable" car il pourra être compilée pour toutes les plateforme grâce au fait que gcc soit lui-même portable.
Après, avoir un environnement de développement "portable" est, je pense, plus qu'utile lorsqu'on travaille en équipe.

Je pense que si tu es développeur de bibliothèque, la situation est assez différente de si tu développes des programmes finaux.

Citation:

Envoyé par Neckara

Personnellement, quand j'utilise une fonction, je regarde son man et je vois tout de suite si elle est portable ou non.
Quand j'utilise une bibliothèque, je regarde sur leur site et je vois tout de suite si ce sera portable ou non.
Donc ne pas faire du code portable (à 2-3 rectifications près), c'est pour moi le faire exprès.

J'ai vu tellement de code développé sous linux avec gcc et recompilé, toujours avec gcc, sous windows, mais qui ne fonctionnait pas dès lors qu'on le plaçait à l'endroit standard pour placer ce programme sous windows (dans "program files", note l'espace entre program et files) que je pense que tu sous-estimes le problème. Rien qu'entre linux et windows, il y a tant de différences qui ne se perçoivent pas forcément à travers une API que faire du code portable demande quand même pas mal de connaissance de tous les environnements où le code est porté (fin de ligne des fichiers, casse des noms de fichiers dans l'OS, contraintes de longueurs sur ces noms, gestion de internationalisation, gestion des arguments de ligne de commande, règles de nommage des objets système, possibilités d'actions sur une fichier ouvert par ailleurs...).

Alors, certes, éviter d'utiliser des API spécifiques est un début. De la même manière, utiliser le plus petit dénominateur commun des différents compilateurs que l'on va cibler en terme de langage (et je peux dire qu'il y a dans la nature des compilateurs bien moins conformes que cgg, clang ou visual C++). Mais je n'oserais jamais dire qu'un code est portable sans l'avoir porté et testé.
17/11/2013, 14h44
Iradrille
Citation:

Envoyé par JolyLoic

Oui. C'est le standard de fait sous windows. Il ne brille peut-être pas par son respect de la norme (même si je trouve qu'avec les additions récentes, il a suffisamment rattrapé son retard pour que ce dernier soit devenu une gêne et non plus un handicap), mais ce n'est pas là qu'est sa force. Sa force réside avant tout dans l'écosystème qu'il y a autour : Déjà l'environnement de développement pour lequel je n'ai pas vu d'équivalent, bien qu'en ayant essayé d'autres (après, mon habitude de celui-ci constitue certainement un biais, mais j'ai essayé d'être objectif. Et je n'ai pas non plus testé xcode. Peut-être arrive-t-il au niveau?). Ensuite toutes les bibliothèques disponibles (la plupart des bibliothèques open-source, et tout un tas de bibliothèques closed-source spécifiques windows). Et puis les outils de débug, perfs...

Tout pareil, VS c'est un IDE fantastique, le compilo à du retard su le support du C++11, mais ils vont dans le bon sens, j'suis plutôt confiant sur un support total (ou quasi total) d'ici quelques années.

Citation:

Envoyé par Neckara

Personnellement, quand j'utilise une fonction, je regarde son man et je vois tout de suite si elle est portable ou non.
Quand j'utilise une bibliothèque, je regarde sur leur site et je vois tout de suite si ce sera portable ou non.
Donc ne pas faire du code portable (à 2-3 rectifications près), c'est pour moi le faire exprès.

Il y à des cas un peu plus tordus : l'ajout semi auto des include avec Visual assist par exemple, souvent c'est correct, desfois il utilise des '\' à la place des '/'. Si on fait pas gaffe on à du code non portable, et ça compile sans aucun warnings :/
Il y à aussi des différences au niveau des templates : VS ne vérifie la syntaxe des templates qu'à l'instanciation, alors que GCC vérifie tout le temps (la norme ne dit rien la dessus).
Code:

1 2 3 4 5 6 7 8 9 template <class T> T foo() { T t // ; manquant return T; } int main() { return 0; }
Ceci compile sans warnings sur VS, mais ne compile par sur GCC. (Bien sur si on instancie le template ça ne compile plus).

Alors oui, c'est des erreurs stupides et rapidement corrigées. M'enfin, toujours chiant ces différences.
18/11/2013, 23h54
Arzar

Voilà un sujet qui tombe à pic, Microsoft vient tout juste de publier sont CTP de novembre pour Visual Studio 2013 !

http://www.microsoft.com/en-us/downl....aspx?id=41151

Comme l'an dernier à la même date, le CTP de novembre permet d'intégrer tout au lot de nouvelles features C++11 et C++14 au compilateur de VS.

Au menu, *plein* de bonne choses, en fait on peut même dire que ce CTP vient combler les quelques trous criants qu'il restait dans l'implémentation du C++11 de VS : la génération automatique des move constructor, constexpr et noexcept !

(Attention par contre, car comme pour le précédent CTP, ces améliorations ne concernent que le compilateur, la bibliothèque standard et intellisense n'a pas encore été mis à jour.)

Citation:

implicit move special member function generation (thus also completing =default)
Reference qualifiers on member functions (a.k.a. "& and && for *this")
Thread-safe function local static initialization (a.k.a. "magic statics")
Inheriting constructors
alignof/alignas
__func__
Extended sizeof
constexpr (except for member functions)
noexcept (unconditional)
C++14 decltype(auto)
C++14 auto function return type deduction
C++14 generic lambdas (with explicit lambda capture list)
(Proposed for C++17) Resumable functions and await

Un résumé des nouvelles features sous forme vidéo par STL : http://channel9.msdn.com/Series/C9-L...C-/Core-Cpp-10
19/11/2013, 02h03
germinolegrand

Exact Arzar, merci d'avoir cité les infos :ccool: !
19/11/2013, 13h23
Bousk

Je suis surpris de voir l'implémentation de explicit cité, j'utilise Visual Studio 2010 et j'étais sur qu'il fonctionne déjà. Je l'ai utilisé pas plus tard que la semaine dernière et la conversion implicite avait bien disparu..
19/11/2013, 16h42
r0d

Citation:

Envoyé par Bousk

Je suis surpris de voir l'implémentation de explicit cité, j'utilise Visual Studio 2010 et j'étais sur qu'il fonctionne déjà. Je l'ai utilisé pas plus tard que la semaine dernière et la conversion implicite avait bien disparu..

Moi je ne comprend pas du tout de quoi est question en fait.
J'utilisais explicit il y a dix ans. Ensuite j'ai perdu petit à petit l'habitude de l'utiliser, et ça fait des années que je ne m'en suis pas servi. Mais ce que je peux dire, c'est que explicit existe depuis au moins 10 ans, depuis VS6 au moins.
19/11/2013, 17h36
Médinoc

Si j'ai bien compris, explicit existait dans un sens (constructeur) mais pas dans l'autre (operator type), soit dans Visual, soit dans le standard.