Prise en charge de Visual Studio pour les nouvelles normes C / C ++?

Je continue à lire sur C99 et C ++ 11 et toutes ces choses totalement douces qui sont ajoutées au standard du langage et qui pourraient être agréables à utiliser un jour. Cependant, nous languissons actuellement au pays de l'écriture de C ++ dans Visual Studio.

Les nouveautés de la norme seront-elles jamais ajoutées à Visual Studio, ou Microsoft est-il plus intéressé par l'ajout de nouvelles variantes C # pour ce 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 précisément, cet article:

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

Très utile. Merci!

MS a une série de réponses publiques à cela, la plupart blâmant leurs utilisateurs. Comme celui-ci:

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

Maintenant, l'équipe du compilateur Visual C ++ reçoit parfois la question de savoir pourquoi nous n'avons pas implémenté C99. C'est vraiment basé sur l'intérêt de nos utilisateurs. Là où nous avons reçu de nombreuses demandes pour certaines fonctionnalités du C99, nous avons essayé de les implémenter (ou analogues). A Exemples de couple sont des macros variadique, long long, __pragma, __FUNCTION__et __restrict. S'il y a d'autres fonctionnalités du C99 que vous trouverez utiles dans votre travail, faites-le nous savoir! Nous n'entendons pas grand-chose de nos utilisateurs C, alors parlez et faites-vous entendre

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

Salut: malheureusement, la réaction écrasante que nous recevons de la majorité de nos utilisateurs est qu'ils préféreraient que nous nous concentrions sur C ++ - 0x plutôt que sur C-99. Nous avons sélectionné certaines fonctionnalités populaires du C-99 (macros variadiques long long), mais au-delà de cela, il est peu probable que nous fassions beaucoup plus dans l'espace C-99 (du moins à court terme).

Grottes de Jonathan

Équipe du compilateur Visual C ++.

C'est une situation assez triste, mais qui a également du sens si vous pensez que MS veut verrouiller les utilisateurs: il est très difficile de porter du code moderne basé sur gcc dans MSVC, ce que je trouve au moins extrêmement douloureux.

Une solution de contournement existe, cependant: notez qu'Intel est beaucoup plus éclairé à ce sujet. le compilateur Intel C peut gérer le code C99 et a même les mêmes indicateurs que gcc, ce qui facilite le portage du code entre les plates-formes. En outre, le compilateur Intel fonctionne en studio visuel. Ainsi, en supprimant MS COMPILER, vous pouvez toujours utiliser MS IDE que vous pensez avoir 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. La portabilité du code sur Windows-Linux-Solaris-AIX-etc est généralement importante dans mon expérience, et cela n'est malheureusement pas du tout pris en charge par les outils MS.

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

Il est parmi les auteurs du nouveau modèle de mémoire C ++ normalisé 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

avoir son nom dessus. Donc je suppose que l'inclusion sur Windows de C ++ 0x est assurée tant que H. Sutter reste chez Microsoft.

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

• Les fonctionnalités C99 les plus intéressantes sont déjà présentes en C ++ (inlining, déclaration de variable n'importe où, // commentaires, etc.) et probablement déjà utilisables en C dans Visual Studio (si seulement faire du code C dans le compilateur C ++). Voir ma réponse ici pour une discussion plus complète sur les fonctionnalités C99 en C ++.
• C99 augmente la divergence entre C et C ++ en ajoutant des fonctionnalités déjà existantes en C ++, mais de manière incompatible (désolé, mais l' implémentation complexe booléenne 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 ++ sous Windows semble trop importante pour être ignorée
• .NET est la façon dont Microsoft veut que les gens programment sur Windows. Cela signifie C #, VB.NET, peut-être C ++ / CLI.

Alors, serais-je Microsoft, pourquoi implémenterais-je des fonctionnalités que peu de gens utiliseront jamais alors que les mêmes fonctionnalités sont déjà proposées dans des langues plus actives dans la communauté déjà utilisées 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 du C99 non déjà implémentées ne le seront pas dans les prochaines années, à moins que quelque chose de dramatique ne se produise (un pays plein de développeurs C99 apparaît de nulle part?)

Modifier 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
^ _ ^

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

Modifier 03/05/2012

Herb Sutter a précisé que:

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

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

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

À partir de la version préliminaire 1 de VC2013 , C99, un ensemble plus diversifié de C ++ 11 et certaines normes C ++ 14 nouvellement introduites sont pris 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

Mettre à jour:

Depuis 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 terminée, à l'exception de tgmath.h (non pertinent en C ++) et des macros pragma CX_LIMITED_RANGE / FP_CONTRACT.

Consultez cet article 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 .

J'ai été impliqué dans les travaux ISO C ++ (2000-2005) et Microsoft a apporté d'importantes contributions à ce langage. Il ne fait aucun doute qu'ils fonctionneront sur C ++ 0x, mais ils auront besoin d'un peu plus de temps que de dire Intel. Micosoft doit gérer une base de code plus large qui utilise souvent leurs extensions propriétaires. Cela fait simplement un testfase plus long. Pourtant, ils prendront en charge la plupart de C ++ 0x à terme (l'exportation n'est toujours pas appréciée, du moins si je comprends bien).

En ce qui concerne ISO C, les personnes travaillant 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 sur C99? Bien sûr, Microsoft a sélectionné des pièces de rechange, mais c'est une affaire sensée. Ils en auraient de toute façon besoin pour C ++ 0x, alors pourquoi attendre?

Le support MSVC pour C fait malheureusement très défaut. Il ne prend en charge que la partie de C99 qui est un sous-ensemble de C ++ ... ce qui signifie que, par exemple, il est physiquement impossible de compiler ffmpeg ou ses bibliothèques libav * dans MSVC, car ils utilisent de nombreuses fonctionnalités C99 telles que les éléments struct nommés. Cela 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 fait un effort pour supporter 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é via une fonction d'alignement de pile basée sur un assemblage explicite, de sorte que toutes les fonctions qui nécessitent une pile alignée doivent être désactivées. Cela a également été très ennuyeux de ne pas pouvoir utiliser de vararrays non plus; c'est peut-être pour le mieux, car apparemment GCC les pessimise massivement en termes de performances.

Un article plus récent sur la compatibilité des fonctionnalités C ++ 11 de MSVC pour MSVC 2010 et 2011 est maintenant en ligne .

Microsoft n'a jamais manifesté de réel intérêt à se tenir au courant de la norme c99 (qui vieillit maintenant). Triste pour les programmeurs C, mais je soupçonne que Microsoft se soucie davantage de la communauté C ++.

Visual C ++ 2008 SP1 contient au moins des parties de TR1, et de temps en temps, l'équipe de Visual C ++ blogue ou parle de C ++ 0x, donc je suppose qu'ils le prendront en charge à un moment donné dans la fonctionnalité. Je n'ai cependant rien lu d'officiel.

Informations mises à jour à ce sujet:

Il existe maintenant (10 novembre 2008) un "Community Tech Preview" (CTP) de VS2010 qui contient un aperçu de VC10 qui a certaines parties de C ++ 0x implémentées (notez que VC10 n'aura pas l'ensemble complet de C ++ 0x modifications implémentées même lorsque VC10 est publié):

http://www.microsoft.com/downloads/details.aspx?FamilyId=922B4655-93D0-4476-BDA4-94CF5F8D4814&displaylang=en

Quelques détails sur les nouveautés du VC10 CTP:

• Visual Studio 2010 CTP publié
• Lambdas, auto et static_assert: fonctionnalités C ++ 0x dans VC10, partie 1

Comme indiqué dans l'article ci-dessus, «Le compilateur Visual C ++ dans le Microsoft Visual Studio 2010 September Community Technology Preview (CTP) contient la prise en charge de quatre fonctionnalités de langage C ++ 0x, à savoir:»

• lambdas,
• auto,
• static_assert,
• références rvalue

Herb Sutter est le président de l'organisme de normalisation ISO C ++ et travaille également pour Microsoft. Je ne connais pas le standard Visual Studio C - principalement parce que je n'utilise jamais du C pur - mais Microsoft essaie certainement de faire avancer le nouveau standard C ++. La preuve en est - comme OregonGhost l'a mentionné - le TR1 qui est inclus dans la dernière version de service de Visual Studio.

L'équipe Visual C ++ a publié un tableau des fonctionnalités C ++ 0x que la version 2010 prend en charge à http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-language -fonctionnalités-dans-vc10-la-table.aspx . Comme il peut y avoir un décalage entre la spécification et la mise en œuvre, cela semble assez raisonnable. Wikipedia a un bel article sur les spécifications. Ce n'est pas fini au moment où j'écris ceci.

Le Visual C ++ Bloq fournit de nombreuses informations sur plusieurs points intéressants concernant la prise en charge de C ++ 11 dans VC ++ 11, y compris plusieurs tables

• Fonctionnalités de base du langage C ++ 11
• Fonctionnalités principales du langage C ++ 11: concurrence
• Fonctionnalités principales du langage C ++ 11: C99
• Tailles des conteneurs x86 (octets)
• Tailles des conteneurs x64 (octets)

Blog de l'équipe Visual C ++, fonctionnalités C ++ 11 dans Visual C ++ 11