MS имеет ряд общедоступных ответов на это, большинство из них обвиняющий их пользователей. Как этот:
http://blogs.msdn.com/vcblog/archive/2007/11/05/iso-c-standard-update.aspx
Теперь, команда компилятора Visual C++ получает иногда вопрос относительно того, почему мы haven’t реализовали C99. It’s действительно на основе интереса от наших пользователей. Где we’ve получил много запросов на определенные функции C99, we’ve пытался реализовать их (или аналоги). Пара примеров является variadic макросами,
long long
,__pragma
,__FUNCTION__
, и__restrict
. Если существуют другие функции C99, которые you’d находят полезными в Вашей работе, сообщают нам! Мы don’t слышат много от наших пользователей C, поэтому говорим и делаем себя, слышал
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=345360
Привет: к сожалению, подавляющая обратная связь, которую мы получаем от большинства наших пользователей, - то, что они предпочли бы, чтобы мы сфокусировались на C ++-0x вместо на C-99. Мы "избирательно подошли к выбору" определенных популярных функций C-99 (variadic макросы,
long long
), но вне этого мы вряд ли сделаем намного больше в пространстве C-99 (по крайней мере, в ближайшей перспективе).Jonathan Caves
Команда Компилятора Visual C++.
Это - довольно удручающее состояние дел, но также и имеет смысл, если Вы подозреваете, что MS хочет привязать пользователей: это делает его очень трудно для портирования современного находящегося в gcc кода в MSVC, который, по крайней мере, я нахожу чрезвычайно болезненными.
обходное решение А существует, хотя: Обратите внимание, что Intel намного более просвещен на этом. Intel C compiler может обработать код C99 и даже имеет те же флаги как gcc, делая намного легче портировать код между платформами. Кроме того, компилятор Intel работает в Visual Studio. Таким образом путем фрагментирования КОМПИЛЯТОРА MS можно все еще использовать IDE MS, что Вы, кажется, думаете, имеет некоторое значение, и используйте C99 для своего содержания основ.
А более разумный подход должен честно отодвинуться к Intel CC или gcc, и использовать Eclipse для Вашей среды программирования. Мобильность кода через Windows-Linux-Solaris-AIX-etc обычно важна, по моему опыту, и это нисколько не поддерживается инструментами MS, к сожалению.
Herb Sutter является председателем организации по стандартизации C++ ISO и также работает на Microsoft. Я не знаю о Visual Studio C стандарт - главным образом, потому что я никогда не использую плоскость C - но Microsoft уверена попытка продвинуть новый стандарт C++. Доказательство этого - как упомянутый OregonGhost - TR1, который включен в последний Сервисный Выпуск Visual Studio.
Visual C++ 2 008 SP1 содержат части TR1, по крайней мере, и время от времени, команда Visual C++, ведет блог или говорит о C++ 0x, таким образом, я предполагаю, что они будут поддерживать его в некоторое время в функции. Я не считал ничего официального все же.
Microsoft никогда не выражала реального интереса к хранению до скорости с c99-стандартом (который становится старым к настоящему времени). Печальный для C-программистов, но я подозреваю, что Microsoft заботится больше о C ++-community.
Обновленная информация об этом:
существует теперь (10 ноября 2008) "Технический Предварительный просмотр Сообщества" (CTP) VS2010, который содержит предварительный просмотр VC10, который имеет [приблизительно 113] части C++ 0x реализованный (обратите внимание, что VC10 не будет иметь полного набора C++ 0x изменениями реализованный, даже когда VC10 выпущен):
Некоторые детали о новые функции и возможности в VC10 CTP:
, Как отмечено в вышеупомянутой статье, "Компилятор Visual C++ в Технологическом предварительном просмотре сообщества (CTP) в сентябре Microsoft Visual Studio 2010 года содержит поддержку четырех C++ 0x функции языка, а именно,":
Поддержке MSVC C, к сожалению, очень недостает. Это только поддерживает часть C99, который является подмножеством C++..., что означает, что, например, физически невозможно скомпилировать ffmpeg или его libav* библиотеки в MSVC, потому что они используют много функций C99 такой как названные элементами структуры. Это усугублено тем, что libavcodec также требует компилятора, который поддерживает выравнивание стека, которое не делает MSVC.
я работаю над x264, который в отличие от ffmpeg делает , прилагают усилие для поддержки MSVC, хотя выполнение так часто было кошмаром в и себя. Это не поддерживает выравнивание стека даже при явной передаче самого высокого вызова функции через явную основанную на блоке функцию выравнивания стека таким образом, все функции, которые требуют выровненного стека, должны быть отключены. Его также очень раздражающий, что я не могу использовать vararrays также; возможно, это для лучшего, с тех пор по-видимому, GCC в широком масштабе pessimizes их мудро производительностью.
Я был вовлечен в работу C++ ISO (2000-2005) и Microsoft, сделанную значительными вкладами в тот язык. Нет сомнения, что они будут работать над C++ 0x, но им будет требоваться немного больше времени, чем говорят Intel. Micosoft должен иметь дело с большей кодовой базой, которая часто использует их собственные расширения. Это просто делает для более длинного testfase. Все же они будут поддерживать большую часть C++ 0x в конечном счете (экспорт все еще не любим, хотя, или таким образом, я понимаю).
Когда дело доходит до ISO C, люди, работающие над стандартом, не являются представительными для рынка Microsofts. Клиенты Microsofts могут использовать C++ 98, если они просто ищут лучший C. Итак, почему Microsoft потратила бы деньги на C99? Несомненно, Microsoft избирательно подошла к выбору частей, но это - нормальный бизнес. Им были бы нужны те для C++ 0x так или иначе, итак, почему ожидают?
Herb Sutter является и стулом и очень активным членом комитета стандартизации C++, а также архитектором программного обеспечения на Visual Studio для Microsoft.
Он среди автора новой модели памяти C++, стандартизированной для C++ 0x. Например, следующие бумаги:
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
имеет его имя на нем. Таким образом, я предполагаю, что включение в Windows C++ 0x гарантируют настолько же долго как H. Sutter остается в Microsoft.
Что касается C99, только частично включенного в Visual Studio, я предполагаю, что это - вопрос приоритетов.
Так, я был бы Microsoft, почему я реализую функции, которые будут когда-либо использовать немного людей, когда те же функции будут уже предложены в большем сообществе активные языки, уже используемые большинством людей?
C++ 0x будет включен как расширение VS 2008, или на следующем поколении (поколения?) Visual Studio.
опции C99, не уже реализованные, не будут в следующих годах, если чего-то поразительного не произойдет (страна, полная разработчиков C99, появляется откуда ни возьмись?)
, По-видимому, "страна, полная разработчиков 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 является достаточно четким, я предполагаю.
Herb Sutter прояснил что:
- Наша основная цель состоит в том, чтобы поддерживать "большинство C99/C11, который является подмножеством C++ ISO 98/C++ 11".
- Мы также по историческим причинам поставляем компилятор C90, который принимает (только) C90, и не C++
- Мы не планируем поддерживать функции ISO C, которые не являются частью или C90 или C++ ISO.
сообщение в блоге добавляют ссылки и дальнейшие объяснения тех решений.
Источник: http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/