Должен ли я использовать ANSI C (C89)?

Это 2012. Я пишу код в C. Должен ли я все еще использовать C89? Есть ли еще компиляторы, которые не поддерживают C99?

Я не против использовать /* */ вместо //.

Я не уверен в C89 forbids mixing declarations and code. Я склоняюсь к идее, что на самом деле более читаемо иметь все объявления в одном месте, а если нет, функция слишком длинная.

VLAs выглядят полезными, но я еще не нуждался в них.

Должен ли я придерживаться C89, если у меня нет веской причины не делать этого? Есть ли другие вещи, которые я не рассматривал?

Ответы

Ответ 1

Если вы не знаете, что вы не можете использовать C99-совместимый компилятор (компилятор Visual Studio C является наиболее известным кандидатом), нет веских оснований для того, чтобы не использовать приятные вещи C99 дают вам.

Однако, даже если вам нужно поддерживать этот компилятор, вы можете использовать некоторые функции C99 - только не все из них.

Одна из особенностей C99, которая невероятно удобна, - это сделать for(int i = ...) вместо того, чтобы объявлять вашу переменную цикла поверх функции - тем более, что C фактически имеет область блока. То, что вид объявления, где его сверху, действительно не улучшает читаемость.

Ответ 2

Существует причина (или многие), почему C89 был заменен на C99. Если вы точно знаете, что компилятор C99 не доступен для вашей конкретной работы (маловероятно, если вы не застряли с Visual Studio, который никогда не поддерживал C в любом случае), тогда вам нужно остаться с C89, но в противном случае вы, безусловно, должны где вы сможете воспользоваться последними 20 + годами улучшения. В C99 нет ничего более медленного.

Возможно, вам стоит подумать о новейшем стандарте C11. Были некоторые важные исправления для работы с Unicode, которые мог бы извлечь любой программист на C (другие изменения в стандарте абсолютно минимальны)...

Ответ 3

Хороший код - это смесь производительности, масштабируемости, удобочитаемости и ремонтопригодности.

По моему мнению, C99 упрощает чтение и обслуживание кода. Очень, очень немногие компиляторы не поддерживают C99, поэтому я говорю об этом. Используйте имеющиеся у вас инструменты, если вы не уверены, что вам нужно будет скомпилировать ваш проект с компилятором, который требует более раннего стандарта.

Ознакомьтесь с этими ссылками, чтобы узнать больше о преимуществах C99:

http://www.kuro5hin.org/?op=displaystory;sid=2001/2/23/194544/139

http://en.wikipedia.org/wiki/C99#Design

Обратите внимание, что C99 также поддерживает функции библиотеки, такие как snprintf, которые очень полезны и имеют лучшую поддержку с плавающей запятой. Кроме того, я считаю, что макросы чрезвычайно полезны, особенно при работе с приложениями, интенсивно использующими математику (например, криптографические алгоритмы)

Ответ 4

Я не согласен с комментарием Paul R "bottom line". Существует несколько случаев, когда C89 выгоден для переносимости.

  • Ориентирование встроенных систем, которые могут иметь или не иметь компиляторов, поддерживающих C99: https://groups.google.com/forum/#!topic/comp.arch.embedded/WNvhw3T_9pI%5B1-25%5D

  • Ориентация на компилятор TinyCC, который может потребоваться в ограниченной среде, где установка гигантской инструментальной цепочки либо непрактична, либо не разрешена, (TCC больше не разрабатывается, а Bellard в последнем случае в отношении поддержки ISOC99 заключался в том, что он "направлялся в направлении" полного соответствия.)

  • Поддержка динамической компиляции с помощью libtcc (см. выше).

  • Ориентация MSVC, как отмечали другие.

  • Для совместимости источников с проектами, которые могут потребоваться их компанией для использования стандарта C89. Это особенно актуально, если вы пишете библиотеку с открытым исходным кодом и хотите максимизировать свое приложение в какой-то отрасли.

Как отмечалось в Cegfault, некоторые из функций C99, перечисленных в Wikipedia, могут быть очень полезными, но ни один из них я не считаю незаменимым, если ваш приоритет - переносимость, или применяется любая из вышеуказанных причин.

Похоже, Microsoft не изменила свой статус на C99. В ноябре 2016 года SimonRev из Beijer Electronics прокомментировал связанный с ней