¿Cuándo deberían los nuevos proyectos C apuntar a estándares C muy antiguos (> 20 años, es decir, C89)?

Ocasionalmente veo grandes proyectos C, relativamente nuevos, de código abierto dirigidos a estándares C muy antiguos, típicamente C89. Un ejemplo es systemd. Estos proyectos tienen personas inteligentes al frente, por lo que probablemente tengan una buena razón detrás de esta decisión que no conozco. Dejando a un lado ese beneficio de la duda, casi parece que la razón es "más antigua y estandarizada es siempre más portátil y mejor", lo cual es ridículo porque la conclusión lógica sería que FORTRAN es mejor que C y COBOL es incluso mejor que FORTRAN.

¿Cuándo y por qué se justifica que los nuevos proyectos C apunten a estándares C muy antiguos?

No puedo imaginar un escenario en el que el sistema de un usuario no deba actualizar su compilador de C, sino que sea libre de instalar un nuevo software. La versión LTS de Debian, por ejemplo, tiene un paquete gcc 4.6 que admite C99 y algunos de C11. Sin embargo, supongo que debe existir un escenario extraño y los programas como systemd están dirigidos a esos usuarios.

El caso de uso más razonable que puedo imaginar es cuando se espera que los usuarios tengan arquitecturas exóticas en las que solo hay un compilador C89 disponible, pero están totalmente dispuestos a instalar un nuevo software. Dada la disminución en la diversidad de arquitecturas de conjuntos de instrucciones, parece un escenario excesivamente hipotético, pero no estoy seguro.

... "más antiguo y estandarizado es siempre más portátil y mejor", lo cual es ridículo ...

Esa declaración llegó a ser ridícula cuando mejoró , lo cual es completamente subjetivo. No selecciona un idioma y un estándar para un proyecto porque la mitad de las personas en la última reunión a la que asistió lo estaban usando; lo eliges porque has estudiado y entendido el problema que estás resolviendo y has determinado que es la herramienta adecuada para el trabajo.

Para los estándares en general, hay un caso para algunos proyectos de portabilidad, y ahí es donde seleccionar uno más antiguo tiene algún beneficio. Esto es especialmente cierto cuando se desarrollan bibliotecas como productos, que son un medio para el fin de otra persona. Lo último que desea hacer es escribir algo que no puede vender porque requiere un compilador que los clientes que aún no conoce no pueden tener disponibles. El comentario de Philip Kendall sobre el mundo incrustado es perfecto; hay mucho de eso, ya sea porque la gente todavía tiene que escribir código nuevo para plataformas antiguas y estables o aquellas que no se benefician de las características adicionales y no obtienen un compilador actualizado. Cuando tienes el control total de cada aspecto de tu proyecto, hay "

Para C específicamente, está la cuestión de lo que obtienes a cambio de cumplir con el último estándar. La transición de K & R a C89 fue un gran cambio que requirió mucho esfuerzo para limpiar el código antiguo, pero finalmente hizo mucho bien. Los cambios en C99 y C11son menores en comparación, y la mayoría del encuentro de CI recientemente desarrollado aún pasaría C89 porque no usa las nuevas características. Es difícil argumentar que exigir C99 sobre C89 sería lo correcto porque admite comentarios de una línea, tiene un tipo de datos booleano nativo y puede hacer matrices de longitud variable. Los comentarios y los booleanos tienen soluciones alternativas no feas y los VLA se pueden manejar de otras maneras ligeramente menos eficientes. C11 degradó los VLA a opcionales, y eso podría ser una justificación para elegir el C99 anterior si figuran de manera prominente en su implementación.

Cuando la portabilidad en una amplia gama de plataformas es importante. Eso puede incluir plataformas obsoletas y muchos procesadores integrados para los que solo está disponible un compilador minimalista.

También hay un sentido en el que C89 es el "mínimo común denominador". Fue la primera versión correctamente estandarizada, y se puede suponer que casi cualquier compilador en uso actualmente implementa algún superconjunto de C89.

También está el problema de que Microsoft Visual C ++, si bien era relativamente bueno para mantenerse al día con los estándares de C ++, se atascó en C89 durante mucho tiempo cuando estaba en modo C. Por lo tanto, cualquiera que no use el último Visual Studio puede estar limitado a C89.

Debo admitir que todavía escribo código pseudo-C89 (no totalmente compatible con C99) principalmente debido a Microsoft. Me apoyo mucho en MSVC para el lado de Windows y todavía no son totalmente compatibles con C99, sino que centran su atención en C ++ 17 y en adelante.

Además de eso, estoy trabajando en SDK C contra los cuales muchos desarrolladores de complementos usan MSVC para su desarrollo de complementos, y algunos siguen siendo MSVC 2010. Así que todavía hay compiladores populares que se usan ampliamente en plataformas no tan exóticas (a menos que consideres Windows exótico) que ni siquiera implementan completamente C99 todavía. Cuando apunta a una amplia compatibilidad con la mayor variedad de compiladores (que es una de las razones principales por las que el SDK está escrito en C y no en C ++), todavía hay una gran cantidad de ellos que se usan ampliamente (al menos MSVC) que están atrasados ​​en los tiempos cuando se trata de soporte C. Han pasado casi un par de décadas desde C99 y todavía no tenemos VLA, por ejemplo, en MSVC AFAIK (aún no he verificado MSVC 2017 pero dada la postura de Microsoft sobre C, dudo que sea mucho más compatible con C99) .

Y, por lo tanto, todavía hay desafortunadamente nuevos compiladores que en realidad son bastante buenos con buenos optimizadores y depuradores que aún no son totalmente compatibles con C99. Por supuesto, si no fuera por esto, estaría saltando por todo C11.

Además de la compatibilidad de fuente con complementos y MSVC, también hay interoperabilidad con otros idiomas. Algunos otros idiomas usan el SDK a través de un FFI, y algunos de esos FFI solo entienden C89. Ellos no pueden entender boolo _Boolcomo un simple ejemplo, al importar las funciones de un dylib y sólo comprender, por ejemplo, int.

Sí, el argumento a favor es la portabilidad, pero la pregunta es si realmente hay sistemas no hipotéticos que solo pueden usar un compilador C89 pero están compilando nuevas distribuciones de software. es decir, si estaba comenzando un nuevo proyecto en C, ¿cómo decidiría si adherirme a C89 podría aumentar el número de usuarios potenciales?

Acabo de darme cuenta de esto, pero haciendo eco Blrfl, la ganancia de productividad al usar C99 y C11 no es tan enorme en mi caso, mientras que perder la capacidad de permitir que las personas escriban sus complementos en MSVC podría ser un costo enorme (especialmente porque el producto con el que trabajo on tiene la mayor cuota de mercado, con diferencia, en el lado de Windows y el usuario promedio a menudo compra y descarga muchos complementos de terceros). El tipo de producto en el que trabajo está casi a medio camino entre un entorno de desarrollo para programadores / scripters y un producto de usuario final para artistas, ya que mucha gente quiere desarrollar cosas nuevas para permitir nuevas capacidades y lograr efectos especiales de un personas amables aún no han visto. Entonces, en mi caso, en realidad fue una decisión bastante simple favorecer a C89 al menos para el SDK.

Supongo que tienes que mirar los compiladores que te rodean y tratar de averiguar tu objetivo demográfico. Si no está desarrollando una arquitectura de complementos para Windows o está haciendo una programación integrada o tratando de construir un kit de desarrollo de software que pueda ser utilizado por la más amplia gama de compiladores e idiomas, entonces ciertamente hace que las cosas sean más fáciles de alcanzar para C99 + correctamente lejos. También puede considerar cuánto aumento de productividad obtiene de C99 en adelante. No me beneficio tanto de cosas como los VLA, ya que confío en formas lo suficientemente simples como para usar la pila cuando los datos se ajustan y se acumulan de otra manera.

Pero hay muchas cosas por detrás que van desde compiladores populares como MSVC a FFI en otros lenguajes que son geniales en el sentido de que pueden importar y llamar funciones C directamente desde un dylib, pero también pueden estar un poco atrasados ​​en el veces. Por lo tanto, hay muchas cosas comerciales más prácticas a considerar, dependiendo de su dominio, que simplemente favorecer a los más antiguos y estandarizados para algún tipo de estética.