Когда новые проекты C должны ориентироваться на очень старые стандарты C (> 20 лет, то есть C89)?

Иногда я вижу крупные, относительно новые проекты с открытым исходным кодом C, нацеленные на очень старые стандарты C, обычно C89. Примером является systemd. У этих проектов есть интеллектуальные люди во главе, поэтому у них, вероятно, есть хорошее обоснование этого решения, о котором я не знаю. Помимо этого преимущества сомнений, почти кажется, что логическое обоснование «старше и стандартизированнее, всегда более портативно и лучше», что смешно, потому что логичным выводом будет то, что FORTRAN лучше, чем C, а COBOL даже лучше, чем FORTRAN.

Когда и почему оправдано, что новые проекты C ориентированы на очень старые стандарты C?

Я не могу представить сценарий, когда система пользователя абсолютно не должна обновлять свой компилятор C, но в противном случае она может свободно устанавливать новое программное обеспечение. Например, версия Debian для LTS имеет пакет gcc 4.6, который поддерживает C99 и некоторые из C11. Я предполагаю, что странный сценарий должен существовать, хотя программы типа systemd нацелены на этих пользователей.

Наиболее разумный вариант использования, который я могу себе представить, - это когда пользователи ожидают экзотических архитектур, для которых доступен только компилятор C89, но они полностью готовы установить новое программное обеспечение. Учитывая снижение разнообразия архитектур наборов команд, это кажется чрезмерно гипотетическим сценарием, но я не уверен.

... «старше и стандартизированнее всегда портативнее и лучше», что смешно ...

Это утверждение стало нелепым, когда стало лучше , что совершенно субъективно. Вы не выбираете язык и стандарт для проекта, потому что половина людей на последней встрече, на которую вы ходили, использовали его; Вы выбрали его, потому что изучили и поняли проблему, которую решаете, и определили, что это правильный инструмент для работы.

Что касается стандартов в целом, то для некоторых проектов необходимо сделать вывод о переносимости, и именно здесь выбор более старого варианта имеет некоторую выгоду. Это особенно верно, когда вы разрабатываете библиотеки как продукты, которые являются средством для чьей-либо цели. Последнее, что вы хотите сделать, это написать что-то, что вы не можете продать, потому что для этого требуется компилятор, который клиенты, которых вы еще не встретили, могут быть недоступны. Комментарий Филиппа Кендалла о встроенном мире очень важен; это происходит во многом потому, что людям по-прежнему приходится писать новый код для старых стабильных платформ или те, которые не извлекают выгоду из дополнительных функций и не получают современного компилятора. Когда вы полностью контролируете каждый аспект вашего проекта,

Для C, в частности, возникает вопрос, что вы получаете в обмен на приверженность последним стандартам. Переход с K & R на C89 был большим изменением, которое потребовало много усилий для очистки старого кода, но в конечном итоге принесло много пользы. Эти изменения в C99 и C11по сравнению с ними незначительны, и большая часть недавно разработанного столкновения с КИ все равно будет проходить мимо C89, потому что он не использует новые функции. Трудно утверждать, что использование C99 вместо C89 будет правильным решением, поскольку оно поддерживает однострочные комментарии, имеет собственный тип данных Boolean и может создавать массивы переменной длины. Комментарии и логические значения имеют не уродливые обходные пути, и VLA могут быть обработаны другими, немного менее эффективными способами. C11 понизил VLA до необязательного, и это может быть оправданием для выбора более старого C99, если он занимает заметное место в вашей реализации.

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

Также есть смысл, в котором C89 является «наименьшим общим знаменателем». Это была первая должным образом стандартизированная версия, и можно предположить, что любой используемый сегодня компилятор реализует некоторый расширенный набор C89.

Существует также проблема, заключающаяся в том, что Microsoft Visual C ++, несмотря на то, что он относительно хорошо соответствовал стандартам C ++, долгое время зависал в C89, когда находился в режиме C. Так что любой, кто не использует последнюю версию Visual Studio, может быть ограничен C89.

Я должен признать, что я все еще пишу псевдо-код C89 (не полностью совместимый с C99) в основном из-за Microsoft. Я сильно полагаюсь на MSVC для Windows, и они все еще не полностью совместимы с C99, вместо этого уделяя основное внимание C ++ 17 и более поздним версиям.

Вдобавок ко всему, я работаю над C SDK, против которых многие разработчики плагинов используют MSVC для разработки своих плагинов, а некоторые до сих пор MSVC 2010. Таким образом, все еще существуют популярные компиляторы, которые широко используются на платформах, не столь экзотичных (если вы не считаете, что Windows экзотика), которая даже еще не полностью внедрила C99. Когда вы нацелены на широкую совместимость с наибольшим диапазоном компиляторов (что является одной из основных причин, по которым SDK написан на C, а не на C ++), все еще существует ряд широко используемых (по крайней мере, MSVC), которые отстают от времени когда дело доходит до поддержки C. Прошло уже несколько десятилетий с C99, и у нас до сих пор нет VLA, например, в MSVC AFAIK (еще не проверял MSVC 2017, но, учитывая позицию Microsoft в отношении C, я сомневаюсь, что она гораздо более совместима с C99) ,

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

Помимо совместимости исходного кода с плагинами и MSVC, существует также взаимодействие с другими языками. Некоторые другие языки используют SDK через FFI, а некоторые из этих FFI понимают только C89. Они не могли понять , boolили в _Boolкачестве простого примера при импорте функций из dylib и понять только, скажем, int.

Да, аргумент в пользу переносимости, но вопрос в том, существуют ли на самом деле негипотетические системы, которые могут использовать только компилятор C89, но компилируют новые дистрибутивы программного обеспечения. т.е. если бы я начинал новый проект C, как бы я решил, если присоединение к C89 может увеличить количество потенциальных пользователей?

Только что заметил это, но в некотором роде Blrflэто говорит о том , что прирост производительности при использовании C99 и C11 в моем случае не так уж велик, в то время как потеря возможности разрешать людям писать свои плагины в MSVC может быть огромной ценой (особенно с учетом того, что продукт, на котором я работаю) На данный момент он имеет наибольшую долю рынка на стороне Windows, и средний пользователь часто покупает и загружает множество сторонних плагинов). Продукт, над которым я работаю, находится почти на полпути между средой разработки для программистов / сценаристов и конечным продуктом для художников, так как очень многие люди хотят разрабатывать новые вещи на его основе, чтобы предоставить новые возможности и достичь специальных эффектов Добрые люди еще не видели. Так что в моем случае это было довольно простое решение - отдать предпочтение C89 хотя бы для SDK.

Я полагаю, вам нужно посмотреть на компиляторы вокруг вас и попытаться выяснить вашу целевую демографию. Если вы не разрабатываете архитектуру плагинов для Windows, не занимаетесь встроенным программированием или не пытаетесь создать комплект разработки программного обеспечения, который может использоваться самыми разными компиляторами и языками, то это, безусловно, облегчит работу с C99 +. прочь. Также, возможно, подумайте, какой прирост производительности вы получаете от C99 и выше. Я не сильно выигрываю от таких вещей, как VLA, так как полагаюсь на достаточно простые способы использования стека, когда данные помещаются в кучи, а в остальном - кучи.

Но есть много вещей, отстающих от популярных компиляторов, таких как MSVC, от FFI на других языках, которые классны в том смысле, что они могут импортировать и вызывать функции C напрямую из dylib, но также могут немного отстать раз. Так что в зависимости от вашей области нужно рассмотреть гораздо больше практических бизнес-вещей, чем просто отдать предпочтение старым и стандартизированным для какой-либо эстетики.