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

Я не понимаю, что вы нашли полезного в статье из vcblog за 2008/02 год, поскольку описанные там функции давно существуют в ускоренном режиме и довольно хорошо известны. Изменяющие мир функции C++ 0x отличаются: лямбда-функции, инициализаторы и т. д., Перечисленные в en.wikipedia.org/wiki/C%2B%2B0x.

См. Также недавнюю статью blogs.msdn.com/vcblog/archive/2009/04/22/… (я знаю, что это позже, чем когда был задан вопрос)

Это было значительно улучшено в последних версиях Visual Studio, например в обновлении 2 2015 года: visualstudio.com/en-us/news/vs2015-update2-vs.aspx#Cdoublepl‌ нас.

Попробуйте MinGW-64

«если вы подозреваете, что MS хочет заблокировать пользователей: это очень затрудняет перенос современного кода на основе gcc в MSVC». Вы были бы правы, если бы они решили не реализовывать C++ 0x. Но, судя по всему, они работают (и много работают) над C++ 0x. Так что, я думаю, они не запирают людей ...

Тем не менее, я полагаю, что их истинная причина в том, что они сказали: сообщество C в Windows, возможно, почти не существует или незначительно по сравнению с сообществом C++ / C# /. NET / ASP. Таким образом, у них есть действительная точка зрения. Несмотря на то, что у меня есть Linux и, как и g ++, я не откажусь от MSVC++ только из-за C99, извините.

Если бы они дали нам хотя бы for (int i ;;) и inline.

@Nick: вы можете использовать макрос для определения «inline» для компиляторов, совместимых с C99, и «__inline» для компилятора Visual C. См .: msdn.microsoft.com/en-us/library/z8y1yy88.aspx

re: "блокировка" против gcc: Никогда не приписывайте злому умыслу то, что можно обвинить в некомпетентности.

Лучшая часть их ответа относительно разработки, ориентированной на C++ 0x, заключается в том, что сейчас, более 4 лет спустя, они все еще почти не поддерживают C++ 11. (Между тем gcc поддерживает почти все.)

Я не понимаю, почему Microsoft не может реализовать части C99, которые уже поддерживаются C++ (например, for (int i;;), возможность объявлять локальные переменные где угодно и т. д.). И даже если они не хотят реализовывать некоторые языковые аспекты, по крайней мере, реализовать библиотеки. Соответствующий стандартам snprintf был бы хорошим началом.

@jamesdlin: Читая вопросы и ответы Х. Саттера, я считаю, что компилятор C в Visual Studio предназначен только для исторической поддержки, и его цель - поддерживать C89, ни больше, ни меньше. Тот факт, что вы можете делать все, о чем просили в C++, ограничивая себя C-подобным кодом, может быть еще одной причиной для них не трогать компилятор C. Что касается стандарта snprintf, я думаю, они считают, что можно найти / написать соответствующую версию. Суть в том, что реализация чего-либо означает, что они должны выделить ресурсы на его поддержку, и я думаю, для них нет веских причин делать это для C99.

@paercebal: В первом пункте этого обновления 2012-05-03 (которое вы процитировали в своем ответе) говорится, что их «основная цель - поддерживать большую часть C99 / C11, которая является подмножеством ISO C++ 98 / C++. 11 ". Это многообещающе и сильно отличается от «поддержки C89, не более того».

@jamesdlin: 1. Часть C99 / C11, которая является частью C++ 11, вполне может быть НЕ тем, что вам нужно. . . 2., вы должны знать, что Херб говорит о компиляторе C++, поддерживающем ограниченную часть C99 / C11. Нигде он не писал об обновлении компилятора C для поддержки чего-либо C99 или C11. Заключение: Вы уверены, что это действительно многообещающе для разработчика C, не желающего компилировать с использованием компилятора C++?

@paercebal: 1. В своем предыдущем комментарии я конкретно говорил о функциях C, которые уже были реализованы в C++ (C++ 98, не меньше). 2. Хотя он говорил о компиляторе C++, кажется странным явно упомянуть, что он будет поддерживать функции C99 / C11, которые являются подмножеством C++ 11. Это уже подразумевается, если они заявляют о поддержке C++ 11. Поэтому я считаю, что это подмножество функций также будет доступно при компиляции кода C.

@jamesdlin: Therefore my interpretation is that that subset of features also would be available when compiling C code: Понятно. Я бы тоже сделал такую ​​ошибку. До того, как прочитать этот пост от Херба Саттера, я даже не подозревал, что код компилятора C был навсегда заморожен. . . o.O. . .

FWIW, Предварительный просмотр VC2013 теперь поддерживает стандарты C++ 11 и C99. Проверьте что нового для разработчиков C / C++.

ICC предназначен только для GENUINEINTEL, программы, которые он выводит, будут демонстрировать низкую производительность на процессорах других производителей.

Честно говоря, логическая реализация в C99 была сделана для обеспечения обратной совместимости с нормальным кодом (то есть кодом, который определил, что bool имеет логическое значение).

@Maciej Piechotka: Ты прав. Я точно не помню, что пытался там сделать. Думаю, я перепутал логическое и сложное: хотя комплексный тип C99 - хорошая попытка, он остается особым случаем, который требует появления полного комитета C. А как насчет матриц? или математика / физика векторы? Что смехотворно, так это усилия, необходимые для добавления одного полезного типа в C с поддержкой приведений и операторов, по сравнению с тем же действием в C++. C99 неполный по своей природе. Глядя на функцию _Generic в C1X, я снова вижу то же ограничение, сломанный хак с перегрузкой функций ...

Это: «Самые интересные функции C99 уже присутствуют в C++» - это просто ложь. Шестнадцатеричные средства форматирования с плавающей запятой и литералы. Функции математической библиотеки C99. Именованные инициализаторы для структур / объединений. Ключевое слово restrict. В C++ отсутствует масса замечательных функций C99, и это функции, которые я использую каждый день как программист на C.

@ Стивен Кэнон: Прочтите, пожалуйста, мой ответ: stackoverflow.com/questions/3879636/…. Конечно, это ответ C++ для разработчиков C++, поэтому он не подходит для разработчиков C, не желающих использовать классы, конструкторы или перегруженные математические функции (кому нужен tgmath.h в C++?). Суть в том, что то, что важно, уже есть или легко реализовать. Что касается ключевого слова restrict, вы все еще можете использовать в C++, по-видимому: stackoverflow.com/questions/776283/…. . .

Поддержка restrict в C++ зависит от компилятора, а не от языка. Я заметил, что вы вообще не обращаетесь к шестнадцатеричным числам с плавающей запятой. Именованные инициализаторы для агрегатов намного лучше конструкторов, когда вам не нужны полноценные объекты C++. Я согласен с тем, что tgmacros ужасны, но я ими не пользуюсь. Многие компиляторы C в любом случае поддерживают перегрузку (если мы разрешаем компилятору C++ поддержку restrict, будет справедливо). Дело в том, что они два разных языка с двумя отдельными сообществами пользователей, и это не собирается меняться.

@Stephen Canon: «Я заметил, что вы вообще не обращаетесь к шестнадцатеричным числам с плавающей запятой». Возможно, потому, что эта функция не является принципиальной. Я имею в виду, конечно, для вас это должно быть важно. Но, возможно, большинство разработчиков мало или вообще не заботятся об этой функции. Я, например, не променяю ни одно из недавно добавленных C++ 0x на это шестнадцатеричное представление.

@Stephen Canon: «Многие компиляторы C все равно поддерживают перегрузку»: Не могли бы вы назвать имена компиляторов C, поддерживающих перегрузку функций? Или, может быть, вы говорите о компиляторе C++, компилирующем код в стиле C?

Fwiw Я считаю отсутствие шестнадцатеричных литералов с плавающей запятой позором. И я не думаю, что я одинок с этой точкой зрения. У нас в библиотеке есть форматирование hexfloat. Не будет преувеличением думать, что нам также нужны литералы hexfloat. Я знаю 3 компилятора C++, которые поддерживают это как расширение с включенными правильными флагами.

@ Говард Хиннант: Любая неоптимальная деталь в языке кого-то смущает. Хотя это не демократия, я полагаю, что комитет C++ отдал приоритет тем функциям, которые считались более важными для более широкого сообщества C++. Возможно, для следующей версии C++. То же самое и с Visual C++. Они не «забывают» C99 назло. Они просто отдают приоритет функциям, необходимым их сообществу, и сегодня, я думаю, это C++ 0x.

@paercebal: вы имеете право на эту точку зрения, но в C++ нет ничего, что могло бы побудить меня отказаться от шестнадцатеричных литералов с плавающей запятой. Это как раз моя точка зрения. Конечно Программисты на C++ не заботятся о возможностях C99; наверное, поэтому они программисты на C++. И наоборот, существует целый мир программистов на C, которые совершенно не заботятся о функциях C++ и просто хотят, чтобы Microsoft предоставила компилятор C, который, по крайней мере, пытается придерживаться стандарта, как и все остальные.

Я также хотел бы указать, что Ховард действительно работает в комитете C++ (спасибо, Ховард!) И, по-видимому, точно знает, почему нет шестнадцатеричных литералов с плавающей запятой.

@paercebal: Полностью согласен. Мое намерение состояло в том, чтобы согласиться с тем, что C++ 11 не идеален, я считаю отсутствие шестнадцатеричных литералов дефектом и надеюсь исправить это в будущем. Идеальный стандарт требует бесконечного количества времени, и я очень доволен C++ 11. Насколько мне известно, работа над C++ 1x уже началась, и я надеюсь увидеть там шестнадцатеричные плавающие литералы. У нас уже есть опыт внедрения в этой области, поэтому, по-моему, это выглядит многообещающим. Конечно, никаких гарантий!

@Stephen Canon: «Есть целый мир программистов на C, которым совершенно не интересны функции C++, и они просто хотят, чтобы Microsoft предоставила компилятор C». Почти все C99 имеют эквивалент на C++, что означает, что программисты на C компилятор C++ все еще может иметь свои VLA или что-то еще. И то, что остается нереализуемым, не считается достаточно важным для достаточно большого сообщества, чтобы оправдать время, потраченное на это командой Visual Studio. В конце концов, я полагаю, что важность этого «всего мира программистов на C» - это то, о чем мы не согласны.

@paercebal: «эквиваленты» бесполезны. Существуют миллионы строк переносимого кода C, которые отлично работают на любой другой платформе. Вы предлагаете их переписать? Сообщество пользователей C99 достаточно велико, чтобы другой крупный поставщик компиляторов каждый хотя бы попытался обеспечить совместимость: IBM, HP, Apple, Intel, GNU, Sun, ARM, бесчисленные компиляторы встроенных устройств и т. д. C99 может не иметь значения для программистов Окна, но программы Windows представляют собой крошечную часть всего написанного кода.

@ Говард Хиннант: Вы состоите в комитете C++? Вау!!! Спасибо вам и всем остальным участникам за C++ 0x (или C++ 11, как есть). Это отличная работа, потребовалось время, но эй, это потрясающе!

@Stephen Canon: Ваши аргументы интересны и т. д., Но есть и другие компиляторы, кроме Visual Studio для Windows, некоторые из которых поддерживают C99, поэтому эти «миллионы строк переносимого кода C» все еще можно скомпилировать в Windows. Точно так же, говоря о Sun, их компилятор C++ настолько отсталый, что нам пришлось ограничить возможности C++, которые мы использовали в нашем производственном кроссплатформенном коде. Ну и что? Мы жили с этим и нашли обходные пути. Я уверен, что сообщество C может справиться с тем фактом, что один «тупой» компилятор на одной «тупой» платформе не поддерживает C99. Даже поддержка C1x C99 условна ...

@paercebal: Вы правы, я должен уточнить: я был бы совершенно счастлив, если бы Microsoft признала, что им наплевать на C, и просто прекратила утверждать, что они поставляют компилятор C. Меня совершенно не волнует, поддерживает ли MSVC C.

@ Стивен Кэнон: Точнее. . . 1. Microsoft не раз признавала, что язык C не является их приоритетом. . . 2. Microsoft поставляет компилятор C, который поддерживает C89, но не C99 (и они никогда не заявляли об обратном).

@paercebal, C99 поддерживается начиная с Предварительная версия 1 VC2013 (http://www.microsoft.com/visualstudio/eng/2013-downloads#d-‌ 2013-editions). Посетите [официальный блог.

Насколько я могу судить, только частичная поддержка C99: blogs.msdn.com/b/vcblog/archive/2013/07/19/… "... Мы знаем, что это не полная поддержка функций библиотеки C99."

@ sdfqwerqaz1, см. комментарий STL здесь: "команды компиляторов и библиотек будут рассматривать их в индивидуальном порядке, но наш главный приоритет - соответствие C++. Например, поскольку C++ 11/14 включает стандартную библиотеку C99 по ссылке, предварительная версия 2015 полностью поддерживает C99 Стандартная библиотека (с единственным упущением, это tgmath.h, который требует магии компилятора C и не имеет отношения к C++, который имеет перегрузку, и CX_LIMITED_RANGE / FP_CONTRACT, который также требует поддержки компилятора) ".