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