Треба визнати, що я все ще пишу код псевдо-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. Звичайно, якби не це, я б стрибав по всьому C11.
Окрім сумісності джерел із плагінами та 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 безпосередньо з дилібу, але може також трохи відставати на разів. Таким чином, залежно від вашого домену, слід розглянути набагато більше практичних речей, ніж просто віддавати перевагу старшим та стандартизованим для певного естетичного.