Я обычно пишу код C на C89, теперь некоторые функции C99 (например, intxx_t или __VA_ARGS__ или snprintf) очень полезны и могут быть даже жизненно важными.
До того, как я стал более моим требованием от C89 до C99, я хотел знать, какие из функций C99 были широко поддерживаются и какие из них не получили широкого распространения или даже считались вредными.
Я знаю, что мы могли бы просто проверить нашу поддержку целевого компилятора, но это значительно сократит нашу поддержку, и поскольку это для программного обеспечения с открытым исходным кодом, я предпочел бы иметь более широкую поддержку.
Например, мы используем компилятор Solaris (suncc) и gcc, но может быть и другой компилятор, который мы бы ушли с пути, пока мы могли поддерживать совместимость с очень небольшими усилиями.
Например, я никогда не работал в Windows и ничего не знал о компиляторах Windows, но было бы хорошо поддерживать совместимость с Windows.
Некоторые функции C99 являются необязательными, поэтому их недостаток не является технически несоответствующим. Я не буду различать ниже.
Хмм, выигрыш не имеет <stdint.h>, хотя есть версия stdint.h с открытым исходным кодом для Microsoft. Даже когда файл реализован, многие из отдельных типов отсутствуют.
Сложная и мнимая поддержка часто отсутствует или нарушена.
Расширенные идентификаторы и широкие символы могут быть проблемными точками.
Смотрите этот список проблем с C99 в gcc.
goto по-прежнему считается вредным.
Как-то я собрал четыре голоса. Я представил вышеприведенное выражение, чтобы добавить легкомыслие, и только 30% серьезно относятся к концепции, лежащей в его основе.
Я ожидаю, что подавляющее большинство голосов принадлежит молодым людям, которые не понимают историю языков программирования. Не каждый goto является злым, но по сравнению с 100% незаменимым кодом спагетти, над которым я работал (миллионы строк FORTRAN 66), разумно и продуктивно заменить столько операторов goto на структурированные утверждения (for, while, do .. while, switch). Но иногда goto просто отлично, когда он избегает сложности, например, дополнительные переменные флага, чтобы вырваться из нескольких вложенных циклов.
Ну, gcc в основном будет gcc, независимо от того, на какую рабочую ОС вы нацеливаетесь.
Visual С++, являясь в основном компилятором на С++, не совсем интересуется спецификацией C99. stdint.h объявляет ваши любимые макросы intxx_t. __VA_ARGS__. _Bool, _Complex и _Pragma не реализованы в компиляторе Microsoft Visual С++. Я почти уверен, что поля в printf/scanf не были реализованы, хотя, возможно, VC2010 справляется с ними. snprintf присутствует, но имеет ведущую подчеркивание и немного другую семантику.
Короткий ответ: "Более простая" функция C99 - реализовать без изменения грамматики компилятора или замены стандартной библиотеки, тем более вероятно, что VС++ должен ее поддерживать. Если есть конфликт между C99 и С++, ожидайте, что С++ выиграет.
Runtime sizeof - это кошмар авторов компилятора. Поэтому я считаю вредным.
glibc не реализует C99-совместимый realloc, поэтому realloc(ptr, 0) не переносится.
restrict стало ключевым словом в C99. Это реализация, посягающая на пространство имен пользователей. Если у вас есть действующая программа C89, содержащая слово restrict, вы должны изменить свою программу, чтобы она работала с C99. Другими словами: нет обратной совместимости. Если они собираются нарушить обратную совместимость, они должны были сначала удалить gets из стандарта.
Общие математические функции типа от <tgmath.h> не обязательно широко реализованы, хотя они, похоже, снабжены GCC 4.2.1 на MacOS X 10.6.2.