Поддержка Visual Studio для новых стандартов C / C ++?

Question

Я продолжаю читать о C99 и C ++ 11 и обо всех этих совершенно приятных вещах, которые добавляются в языковой стандарт, который может быть когда-нибудь полезно использовать. Однако в настоящее время мы томимся в области написания C ++ в Visual Studio.

Будет ли когда-нибудь добавлено что-либо из нового стандарта в Visual Studio, или Microsoft больше заинтересована в добавлении новых вариантов C # для этого?

Редактировать: В дополнение к принятому ответу, я нашел блог команды Visual C ++:

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

А конкретно этот пост в нем:

http://blogs.msdn.com/vcblog/archive/2008/02/22/tr1-slide-decks.aspx

Очень полезно. Спасибо!

Answer 1

MS имеет ряд публичных ответов, большинство из которых обвиняют своих пользователей. Как этот:

http://blogs.msdn.com/vcblog/archive/2007/11/05/iso-c-standard-update.aspx

Теперь команда компиляторов Visual C ++ иногда получает вопрос о том, почему мы не внедрили C99. Это действительно основано на интересе наших пользователей. Там, где мы получили много запросов на определенные функции C99, мы пытались реализовать их (или аналоги). Примерами пар являются макросы типа variadic, long long, __pragma, __FUNCTION__ и __restrict. Если есть другие функции C99, которые вам пригодятся в вашей работе, сообщите нам! Мы мало что слышим от наших пользователей C, так что говорите сами и пусть вас услышат

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

Привет: к сожалению, подавляющий отклик, который мы получаем от большинства наших пользователей, заключается в том, что они предпочли бы, чтобы мы сосредоточились на C ++ - 0x, а не на C-99. У нас есть «избранные черри» некоторые популярные функции C-99 (variadic macro, long long), но помимо этого мы вряд ли сделаем гораздо больше в пространстве C-99 (по крайней мере, в краткосрочной перспективе).

Пещеры Джонатана

Команда компилятора Visual C ++.

Это довольно печальное положение вещей, но также имеет смысл, если вы подозреваете, что MS хочет заблокировать пользователей: очень сложно портировать современный код на основе gcc в MSVC, что, по крайней мере, мне кажется крайне болезненным.

Однако существует обходной путь: обратите внимание, что Intel гораздо лучше осведомлена об этом. Компилятор Intel C может обрабатывать код C99 и даже имеет те же флаги, что и gcc, что значительно упрощает перенос кода между платформами. Также компилятор Intel работает в visual studio. Таким образом, отказавшись от MS COMPILER, вы все равно можете использовать MS IDE, которая, как вам кажется, имеет какую-то ценность, и использовать C99 для своего сердца.

Более разумный подход - честно перейти на Intel CC или gcc и использовать Eclipse для своей среды программирования. В моем опыте обычно важна переносимость кода между Windows-Linux-Solaris-AIX и т. Д., К сожалению, это совсем не поддерживается инструментами MS.

Answer 2

Херб Саттер является председателем и очень активным членом комитета по стандартизации C ++, а также архитектором программного обеспечения в Visual Studio для Microsoft.

Он является одним из авторов новой модели памяти C ++, стандартизированной для C ++ 0x. Например, следующие документы:

http://www.open -std.org / jtc1 / sc22 / wg21 / docs / documents / 2008 / n2669.htm
http://www.open -std.org / ОТК1 / SC22 / wg21 / документы / документы / 2007 / n2197.pdf

На нем его имя. Поэтому я предполагаю, что включение в Windows C ++ 0x гарантировано, пока Х. Саттер остается в Microsoft.

Что касается C99, только частично включенного в Visual Studio, я думаю, что это вопрос приоритетов.

• Наиболее интересные функции C99 уже присутствуют в C ++ (встраивание, объявление переменных в любом месте, // комментарии и т. Д.) И, вероятно, уже могут использоваться в C в Visual Studio (если только делать код C в компиляторе C ++). Смотрите мой ответ здесь для более полного обсуждения возможностей C99 в C ++.
• C99 увеличивает расхождение между C и C ++, добавляя функции, уже существующие в C ++, но несовместимым способом (извините, но сложная реализация boolean в C99 смешна, в лучшем случае ... Смотрите http://david.tribble.com/text/cdiffs.htm для получения дополнительной информации)
• Сообщество C в Windows кажется несуществующим или недостаточно важным, чтобы его можно было признать
• Сообщество C ++ в Windows кажется слишком важным, чтобы его игнорировать
• .NET - это способ, которым Microsoft хочет, чтобы люди программировали под Windows. Это означает C #, VB.NET, возможно C ++ / CLI.

Итак, буду ли я Майкрософт, зачем мне внедрять функции, которые мало кто когда-либо будет использовать, когда те же функции уже предлагаются на более активных языках сообщества, уже используемых большинством людей?

Заключение

C ++ 0x будет включен, как расширение VS 2008, или в следующем поколении (поколениях?) Visual Studio.

Функции C99, еще не реализованные, не появятся в ближайшие годы, если только не произойдет что-то драматическое (страна, полная разработчиков C99, появляется из ниоткуда?)

Редактировать 2011-04-14

Очевидно, "страна, полная разработчиков C99" уже существует: http://blogs.msdn.com/vcblog/archive/2007/11/05/iso-c-standard-update.aspx#6415401
^ _ ^

Тем не менее, последний комментарий по адресу: http://blogs.msdn.com/vcblog/archive/2007/11/05/iso-c-standard-update.aspx#6828778 достаточно ясен, я думаю.

Редактировать 2012-05-03

Херб Саттер дал понять, что:

1. Наша основная цель - поддерживать «большую часть C99 / C11, которая является подмножеством ISO C ++ 98 / C ++ 11».
2. Мы также по историческим причинам поставляем компилятор C90, который принимает (только) C90, а не C ++
3. Мы не планируем поддерживать функции ISO C, которые не являются частью C90 или ISO C ++.

В блоге добавляются ссылки и дополнительные пояснения к этим решениям.

Источник: http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

Answer 3

Начиная с Предварительный просмотр VC2013 1 , C99, поддерживается более разнообразный набор C ++ 11 и некоторые недавно представленные стандарты C ++ 14. Проверьте официальный блог для более подробной информации: http://blogs.msdn.com/b/vcblog/archive/2013/06/27/what-s-new-for-visual-c-developers-in-vs2013-preview.aspx

Обновление:

С https://news.ycombinator.com/item?id=9434483 (Стефан Т Лававей, он же: STL - сопровождающий команды STL @VC):

В частности, в 2015 году реализация стандартной библиотеки C99 будет завершена, за исключением tgmath.h (не относится к C ++) и прагматических макросов CX_LIMITED_RANGE / FP_CONTRACT.

Проверьте это сообщение для деталей: http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx.

Answer 4

Я принимал участие в работе над ISO C ++ (2000-2005), и Microsoft внесла значительный вклад в этот язык. Нет сомнений, что они будут работать на C ++ 0x, но им потребуется немного больше времени, чем, скажем, на Intel. Micosoft имеет дело с большей кодовой базой, которая часто использует свои проприетарные расширения. Это просто делает для более длинной тестовой базы. Тем не менее, они в конечном итоге будут поддерживать большую часть C ++ 0x (хотя экспорт по-прежнему не нравится, или я так понимаю).

Когда дело доходит до ISO C, люди, работающие над стандартом, не являются репрезентативными для рынка Microsoft. Клиенты Microsoft могут использовать C ++ 98, если они просто ищут лучшую версию C. Так зачем Microsoft тратить деньги на C99? Конечно, Microsoft выбрала запчасти, но это нормальное дело. В любом случае, они нужны для C ++ 0x, так зачем ждать?

Answer 5

Поддержка MSVC для C, к сожалению, очень отсутствует. Он поддерживает только часть C99, которая является подмножеством C ++ ... что означает, что, например, физически невозможно скомпилировать библиотеки ffmpeg или его libav * в MSVC, поскольку они используют многие функции C99, такие как именованные элементы структуры. Это усугубляется тем фактом, что libavcodec также требует компилятор, поддерживающий выравнивание стека, чего нет у MSVC.

Я работаю на x264, который, в отличие от ffmpeg , прилагает усилия для поддержки MSVC, хотя это часто было кошмаром само по себе. Он не поддерживает выравнивание стека, даже если вы явно передаете самый высокий вызов функции через явную функцию выравнивания стека на основе сборки, поэтому все функции, которым требуется выровненный стек, должны быть отключены. Также было очень неприятно, что я тоже не могу использовать vararrays; возможно, это к лучшему, так как, очевидно, GCC массово пессимизирует их с точки зрения производительности.

Answer 6

Более свежая статья о совместимости MSVC C ++ 11 для MSVC 2010 и 2011: сейчас в сети .

Answer 7

Обновлена ​​информация по этому вопросу:

В настоящее время (10 ноября 2008 г.) "Community Tech Preview" (CTP) VS2010 содержит предварительный просмотр VC10, в котором реализовано некоторых частей C ++ 0x (обратите внимание, что VC10 не будет иметь полный набор изменений C ++ 0x, реализованных даже после выпуска VC10):

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

Некоторые подробности о том, что нового в VC10 CTP:

• Выпущена CTP-версия Visual Studio 2010
• Lambdas, auto и static_assert: Особенности C ++ 0x в VC10, часть 1

Как отмечалось в вышеприведенной статье, «Компилятор Visual C ++ в сентябрьском предварительном обзоре технологий (CTP) Microsoft Visual Studio 2010 содержит поддержку четырех функций языка C ++ 0x, а именно:«

• лямбды,
• авто,
• static_assert,
• rvalue ссылки

Answer 8

Visual C ++ 2008 SP1 содержит как минимум части TR1, и время от времени команда Visual C ++ ведет блог или говорит о C ++ 0x, поэтому я думаю, что они будут поддерживать его в какой-то момент в этой функции. Хотя я не читал ничего официального.

Answer 9

Microsoft никогда не проявляла особой заинтересованности в том, чтобы идти в ногу со стандартом c99 (который к настоящему времени стареет). Печально для программистов на C, но я подозреваю, что Microsoft больше заботится о сообществе C ++.

Answer 10

Команда Visual C ++ выпустила таблицу возможностей C ++ 0x, поддерживаемых выпуском 2010 года, на уровне http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-language-features-in-vc10-the-table.aspx. Поскольку между спецификацией и реализацией может быть задержка, это кажется довольно разумным. В Википедии есть хорошая статья о спецификации. Это не закончено в то время, когда я пишу это.