Je dois admettre que j'écris toujours du code pseudo-C89 (pas entièrement compatible C99) principalement à cause de Microsoft. Je m'appuie fortement sur MSVC pour le côté Windows et ils ne sont toujours pas entièrement conformes à C99, plaçant plutôt l'essentiel de leur attention sur C ++ 17 et versions ultérieures.
En plus de cela, je travaille sur des SDK C contre lesquels de nombreux développeurs de plugins utilisent MSVC pour leur développement de plugins, et certains encore MSVC 2010. Il existe donc toujours des compilateurs populaires largement utilisés sur des plateformes pas si exotiques (sauf si vous considérez Windows exotiques) qui n'implémentent même pas encore complètement C99. Lorsque vous ciblez une large compatibilité avec la plus grande gamme de compilateurs (ce qui est l'une des principales raisons pour lesquelles le SDK est écrit en C et non en C ++), il y a encore un certain nombre d'entre eux largement utilisés (au moins MSVC) qui sont en retard sur le temps en ce qui concerne le support C. Cela fait presque deux décennies depuis C99 et nous n'avons toujours pas de VLA, par exemple, dans MSVC AFAIK (pas encore vérifié sur MSVC 2017 mais étant donné la position de Microsoft sur C, je doute qu'il soit beaucoup plus conforme à C99) .
Et donc il y a malheureusement encore de nouveaux compilateurs qui sont en fait assez bons avec de bons optimiseurs et débogueurs qui ne sont pas encore entièrement conformes à C99. Bien sûr, sans cela, je sauterais partout en C11.
Outre la compatibilité des sources avec les plugins et MSVC, il existe également une interaction avec d'autres langues. Certaines autres langues utilisent le SDK via un FFI, et certains de ces FFI ne comprennent que C89. Ils pourraient ne pas comprendre boolou _Boolcomme un exemple simple lors de l' importation des fonctions d'un dylib et seulement comprendre, par exemple, int.
Oui, l'argument en faveur est la portabilité, mais la question est de savoir s'il existe réellement des systèmes non hypothétiques qui ne peuvent utiliser qu'un compilateur C89 mais compilent de nouvelles distributions de logiciels. Par exemple, si je commençais un nouveau projet C, comment pourrais-je décider si l'adhésion à C89 pourrait augmenter le nombre d'utilisateurs potentiels?
Je viens de remarquer celui-ci mais en quelque sorte un écho Blrfl, le gain de productivité en utilisant C99 et C11 n'est pas si énorme dans mon cas, tout en perdant la possibilité de permettre aux gens d'écrire leurs plugins dans MSVC pourrait être un coût énorme (surtout depuis le produit sur lequel je travaille) on détient de loin la plus grande part de marché du côté Windows et l'utilisateur moyen achète et télécharge souvent de nombreux plugins tiers). Le type de produit sur lequel je travaille est presque à mi-chemin entre un environnement de développement pour les programmeurs / scripteurs et un produit utilisateur pour les artistes, car beaucoup de gens veulent développer de nouvelles choses en plus pour permettre de nouvelles capacités et obtenir les effets spéciaux d'un les gens gentils n'ont pas encore vu. Donc, dans mon cas, c'était en fait une décision assez simple de favoriser C89 au moins pour le SDK.
Je suppose que vous devez en quelque sorte regarder les compilateurs autour de vous et essayer de comprendre votre groupe démographique cible. Si vous ne développez pas une architecture de plug-in pour Windows, ne faites pas de programmation intégrée ou n'essayez pas de créer un kit de développement logiciel pouvant être utilisé par la plus large gamme de compilateurs et de langages, cela facilite certainement les choses pour C99 +. une façon. Pensez peut-être aussi à la quantité de gains de productivité que vous obtenez à partir du formulaire C99. Je ne profite pas beaucoup de choses comme les VLA, car je compte sur des moyens assez simples pour utiliser la pile lorsque les données sont ajustées et autrement.
Mais il y a beaucoup de choses à la traîne des compilateurs populaires comme MSVC aux FFI dans d'autres langages qui sont cool dans le sens où ils peuvent importer et appeler des fonctions C directement à partir d'un dylib, mais qui pourraient également être un peu en retard sur le fois. Il y a donc beaucoup plus de choses pratiques à considérer, selon votre domaine, que de simplement privilégier les anciennes et les standardisées pour une sorte d'esthétique.