Devo admitir que ainda escrevo código pseudo-C89 (não totalmente compatível com C99) principalmente por causa da Microsoft. Eu me apóio muito no MSVC para o lado do Windows e eles ainda não são totalmente compatíveis com C99, em vez disso, colocando a maior parte de seu foco no C ++ 17 em diante.
Além disso, estou trabalhando em SDKs C contra os quais muitos desenvolvedores de plug-ins usam o MSVC para o desenvolvimento de plug-ins e alguns ainda o MSVC 2010. Portanto, ainda existem compiladores populares amplamente usados em plataformas não tão exóticas (a menos que você considere Windows exótico) que ainda nem implementam completamente o C99. Quando você objetiva ampla compatibilidade com a maior variedade de compiladores (que é um dos principais motivos pelos quais o SDK é escrito em C e não em C ++), ainda há vários deles sendo amplamente utilizados (pelo menos MSVC), que estão atrasados quando se trata de suporte C. Faz quase duas décadas desde o C99 e ainda não temos VLAs, por exemplo, no MSVC AFAIK (ainda não fiz o check-in do MSVC 2017, mas, dada a posição da Microsoft em C, duvido que seja muito mais compatível com o C99) .
Infelizmente, ainda existem novos compiladores que são realmente bons com bons otimizadores e depuradores que ainda não são totalmente compatíveis com C99. Claro que se não fosse por isso, eu estaria pulando por todo o C11.
Além da compatibilidade de fontes com plug-ins e MSVC, também há interoperabilidade com outros idiomas. Alguns outros idiomas usam o SDK por meio de um FFI, e alguns deles compreendem apenas o C89. Eles podem não entender boolou _Boolcomo um exemplo simples ao importar funções de um dylib e entender apenas, digamos int,.
Sim, o argumento a favor é portabilidade, mas a questão é se realmente existem sistemas não hipotéticos que podem usar apenas um compilador C89, mas estão compilando novas distribuições de software. ou seja, se eu estivesse iniciando um novo projeto C, como decidir se a adesão ao C89 poderia aumentar o número de usuários em potencial?
Só notei este, mas meio que ecoando Blrfl , o ganho de produtividade usando C99 e C11 não é tão grande no meu caso, ao mesmo tempo em que perder a capacidade de permitir que as pessoas escrevam seus plugins no MSVC pode ser um custo enorme (principalmente porque o produto em que trabalho) on tem a maior participação de mercado, de longe, no lado do Windows e o usuário médio geralmente compra e baixa muitos plugins de terceiros). O tipo de produto no qual trabalho está quase na metade do caminho entre um ambiente de desenvolvimento para programadores / roteiristas e um produto final para artistas, pois muitas pessoas desejam desenvolver novas coisas para permitir novos recursos e obter efeitos especiais de um artista. pessoas gentis ainda não viram. Então, no meu caso, foi realmente uma decisão muito simples favorecer o C89 pelo menos para o SDK.
Suponho que você precise olhar os compiladores ao seu redor e tentar descobrir o seu público-alvo. Se você não está desenvolvendo uma arquitetura de plug-in para Windows ou está fazendo alguma programação incorporada ou tentando criar um kit de desenvolvimento de software que possa ser usado pela maior variedade de compiladores e idiomas existentes no mercado, certamente tornará as coisas mais fáceis de alcançar para o C99 + longe. Talvez considere também quanto de aumento de produtividade você obtém do formulário C99 em diante. Não me beneficio muito de coisas como VLAs, pois confio em maneiras simples o suficiente de usar a pilha quando os dados se ajustam e se acumulam.
Mas há muitas coisas por trás de compiladores populares como MSVC e FFI's em outros idiomas, que são legais no sentido de que eles podem importar e chamar funções C diretamente de um dylib, mas também podem estar um pouco atrasados no vezes. Portanto, há coisas de negócios muito mais práticas a serem consideradas, dependendo do seu domínio, do que simplesmente favorecer antigas e padronizadas para algum tipo de estética.