Le support de Visual Studio pour les nouvelles normes C / C++ ?

Question

Je n'arrête pas de lire des articles sur C99 et C++11 et sur toutes ces choses totalement adorables qui sont ajoutées à la norme du langage et qui pourraient être intéressantes à utiliser un jour. Cependant, nous nous languissons actuellement au pays de l'écriture du C++ dans Visual Studio.

Les nouvelles fonctionnalités de la norme seront-elles un jour ajoutées à Visual Studio, ou Microsoft est-il plus intéressé par l'ajout de nouvelles variantes de C# pour le faire ?

Edit : En plus de la réponse acceptée, j'ai trouvé le blog de l'équipe Visual C++ :

http://blogs.msdn.com/vcblog/

Et plus particulièrement, ce post dans celui-ci :

https://web.archive.org/web/20190109064523/https://blogs.msdn.microsoft.com/vcblog/2008/02/22/tr1-slide-decks/

Très utile. Merci !

Answer 1

MS a donné une série de réponses publiques à ce sujet, la plupart d'entre elles blâmant leurs utilisateurs. Comme celle-ci :

https://devblogs.microsoft.com/cppblog/iso-c-standard-update/

L'équipe du compilateur Visual C++ reçoit de temps en temps la question de savoir pourquoi nous n'avons pas implémenté C99. C'est vraiment basé sur l'intérêt de nos utilisateurs. Lorsque nous avons reçu de nombreuses demandes pour certaines fonctionnalités de C99, nous avons essayé de les implémenter (ou des analogues). Quelques exemples sont les macros variadiques, long long , __pragma , __FUNCTION__ y __restrict . S'il existe d'autres fonctionnalités de C99 que vous trouveriez utiles dans votre travail, faites-le nous savoir ! Nous n'entendons pas beaucoup parler de nos utilisateurs C, alors parlez et faites-vous entendre.

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=345360

Bonjour : Malheureusement, la majorité des utilisateurs nous disent qu'ils préféreraient que nous nous concentrions sur C++-0x plutôt que sur C-99. Nous avons "cherché" certaines fonctionnalités populaires de C-99 (macros variadiques, long long ) mais au-delà, il est peu probable que nous fassions beaucoup plus dans l'espace C-99 (du moins à court terme).

Jonathan Caves

L'équipe du compilateur Visual C++.

C'est un triste état de fait, mais c'est également logique si l'on soupçonne MS de vouloir enfermer les utilisateurs : cela rend très difficile le portage de code moderne basé sur gcc vers MSVC, ce que je trouve extrêmement pénible.

Il existe cependant une solution de contournement : Notez qu'Intel est beaucoup plus éclairé à ce sujet. Le compilateur C d'Intel peut gérer le code C99 et possède même les mêmes drapeaux que gcc, ce qui facilite grandement le portage du code entre les plateformes. De plus, le compilateur Intel fonctionne dans Visual Studio. Ainsi, en abandonnant le compilateur MS, vous pouvez toujours utiliser l'IDE MS dont vous semblez penser qu'il a une certaine valeur, et utiliser C99 à votre guise.

Une approche plus sensée consiste honnêtement à passer à Intel CC ou gcc, et à utiliser Eclipse pour votre environnement de programmation. D'après mon expérience, la portabilité du code entre Windows-Linux-Solaris-AIX-etc est généralement importante, et les outils MS ne la prennent pas du tout en charge, malheureusement.

Answer 2

Herb Sutter est à la fois le président et un membre très actif du comité de normalisation C++, ainsi qu'architecte logiciel sur Visual Studio pour Microsoft.

Il est notamment l'auteur du nouveau modèle de mémoire C++ standardisé pour C++0x. Par exemple, les articles suivants :

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2669.htm
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2197.pdf

ont son nom dessus. Je suppose donc que l'inclusion de C++0x dans Windows est assurée tant que H. Sutter reste chez Microsoft.

Quant au fait que C99 ne soit que partiellement inclus dans Visual Studio, je suppose que c'est une question de priorités.

• La plupart des fonctionnalités intéressantes de C99 sont déjà présentes en C++ (inlining, déclaration de variables n'importe où, // commentaires, etc.) et probablement déjà utilisables en C dans Visual Studio (si l'on ne fait que du code C dans le compilateur C++). Voir ma réponse aquí pour une discussion plus complète sur les fonctionnalités de C99 dans C++.
• Le C99 accroît la divergence entre le C et le C++ en ajoutant des fonctionnalités qui existent déjà dans le C++, mais de manière incompatible (désolé, mais les boolean L'implémentation complexe en C99 est risible, au mieux... Voir http://david.tribble.com/text/cdiffs.htm pour plus d'informations)
• La communauté C sous Windows semble inexistante ou pas assez importante pour être reconnue.
• La communauté C++ sur Windows semble trop importante pour être ignorée
• .NET est la façon dont Microsoft veut que les gens programment sous Windows. Cela signifie C#, VB.NET, peut-être C++/CLI.

Alors, serais-je Microsoft, pourquoi implémenter des fonctionnalités que peu de gens utiliseront jamais alors que les mêmes fonctionnalités sont déjà offertes dans des langages plus actifs au niveau de la communauté et déjà utilisés par la plupart des gens ?

Conclusion ?

C++0x sera inclus, comme extension de VS 2008, ou sur la prochaine génération (générations ?) de Visual Studio.

Les fonctionnalités de C99 qui n'ont pas encore été implémentées ne le seront pas dans les prochaines années, à moins que quelque chose de dramatique ne se produise (un pays rempli de développeurs C99 apparaît de nulle part ?)

Edition 2011-04-14

Apparemment, le "pays plein de développeurs C99" existe déjà : http://blogs.msdn.com/vcblog/archive/2007/11/05/iso-c-standard-update.aspx#6415401
^_^

Quand même, le dernier commentaire à : http://blogs.msdn.com/vcblog/archive/2007/11/05/iso-c-standard-update.aspx#6828778 est assez clair, je suppose.

Edition 2012-05-03

Herb Sutter l'a clairement dit :

1. Notre objectif principal est de supporter "la plus grande partie de C99/C11 qui est un sous-ensemble de ISO C++98/C++11".
2. Pour des raisons historiques, nous fournissons également un compilateur C90 qui accepte (uniquement) C90 et non C++.
3. Nous ne prévoyons pas de prendre en charge les fonctionnalités de l'ISO C qui ne font pas partie du C90 ou de l'ISO C++.

Le billet de blog ajoute des liens et des explications supplémentaires pour ces décisions.

Source : http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

Answer 3

À partir de VC2013 preview 1 Les normes C++1, C99, un ensemble plus diversifié de normes C++11 et certaines normes C++14 nouvellement introduites sont prises en charge. Consultez le blog officiel pour plus de détails : http://blogs.msdn.com/b/vcblog/archive/2013/06/27/what-s-new-for-visual-c-developers-in-vs2013-preview.aspx

Mise à jour :

De https://news.ycombinator.com/item?id=9434483 (Stephan T Lavavej aka : STL est le mainteneur de l'équipe STL @VC) :

Plus précisément, en 2015, notre implémentation de la bibliothèque standard C99 est complète, à l'exception de tgmath.h (non pertinent en C++) et des macros pragma CX_LIMITED_RANGE/FP_CONTRACT.

Consultez ce post pour plus de détails : http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx .

Answer 4

J'ai participé aux travaux de l'ISO C++ (2000-2005), et Microsoft a apporté des contributions importantes à ce langage. Il ne fait aucun doute qu'ils travailleront sur C++0x, mais ils auront besoin d'un peu plus de temps que, par exemple, Intel. Microsoft doit faire face à une base de code plus importante qui utilise souvent ses extensions propriétaires. Cela rend simplement la base de test plus longue. Pourtant, ils prendront en charge la majeure partie de C++0x à terme (l'exportation n'est toujours pas appréciée, d'après ce que j'ai compris).

En ce qui concerne l'ISO C, les personnes qui travaillent sur la norme ne sont pas représentatives du marché de Microsofts. Les clients de Microsoft peuvent utiliser C++98 s'ils recherchent simplement un meilleur C. Alors pourquoi Microsoft dépenserait-il de l'argent pour C99 ? Bien sûr, Microsoft a sélectionné des parties, mais c'est une affaire saine. Ils en auraient besoin pour C++0x de toute façon, alors pourquoi attendre ?

Answer 5

Le support de MSVC pour le C est malheureusement très insuffisant. Il ne supporte que la partie de C99 qui est un sous-ensemble de C++... ce qui signifie, par exemple, qu'il est physiquement impossible de compiler ffmpeg ou ses bibliothèques libav* dans MSVC, parce qu'ils utilisent de nombreuses fonctionnalités de C99 comme les éléments struct nommés. Ceci est aggravé par le fait que libavcodec nécessite également un compilateur qui maintient l'alignement de la pile, ce que MSVC ne fait pas.

Je travaille sur x264, qui contrairement à ffmpeg hace font un effort pour prendre en charge MSVC, bien que cela ait souvent été un cauchemar en soi. Il ne maintient pas l'alignement de la pile même si vous passez explicitement l'appel de fonction le plus élevé à travers une fonction d'alignement de pile explicite basée sur l'assemblage, donc toutes les fonctions qui nécessitent une pile alignée doivent être désactivées. Il est également très ennuyeux de ne pas pouvoir utiliser les vararrays ; peut-être est-ce pour le mieux, puisqu'apparemment GCC les pessimise massivement en termes de performances.