Qué características C99 se consideran dañinas o no compatibles

Question

Normalmente escribo código C en C89, ahora algunas características de C99 (como intxx_t o __VA_ARGS__ o snprintf) son muy útiles, y pueden ser incluso vitales.

Antes de volver a mis requisitos de C89 a C99, quería saber cuáles de las características de C99 eran ampliamente compatibles y cuáles no eran ampliamente compatibles o incluso se consideraban dañinas.

Sé que podríamos simplemente consultar nuestro soporte de compilación de destino, pero esto reduciría mucho nuestro soporte, y como esto es para el software de código abierto, preferiría tener un soporte más amplio.

Por ejemplo, usamos el compilador Solaris (suncc) y gcc, pero podría haber otro compilador que nos saldría del camino mientras pudiéramos mantener la compatibilidad con muy pocos esfuerzos.

Por ejemplo, nunca trabajé en Windows ni sé nada sobre compiladores de Windows, pero sería bueno mantener la compatibilidad de Windows.

Answer 1

Varias características de C99 son opcionales, por lo que su falta no es técnicamente no conforme. No voy a distinguir a continuación.

• Hmm, la victoria no tiene <stdint.h>, aunque hay an open-source version of stdint.h for Microsoft. Incluso cuando se implementa el archivo, faltan muchos de los tipos individuales.

• Soporte complejo e imaginario a menudo falta o está roto.

• Los identificadores ampliados y los caracteres anchos pueden ser puntos problemáticos.

Ver this list of C99 feature issues in gcc.

Answer 2

goto sigue siendo considered harmful.

---

De alguna manera he recogido cuatro votos negativos. Presenté la declaración anterior para agregar ligereza, y estoy solo un 30% serio sobre el concepto detrás de esto.

Espero que los votos hacia abajo sean de jóvenes que no entienden la historia de los lenguajes de programación. No cadagoto es malo, pero – en comparación con el código espagueti adulterada 100% He trabajado en (millones de líneas de FORTRAN 66) – es razonable y productivo para reemplazar tantos goto declaraciones con declaraciones estructuradas (for, while, do .. while, switch) como sea posible. Pero a veces un goto está bien cuando se evita la complejidad, como las variables de indicador extra para romper múltiples bucles anidados.

Answer 3

Bueno, gcc básicamente va a ser gcc independientemente del sistema operativo de escritorio al que te dirijas.

Visual C++, que es principalmente un compilador de C++, no está tan preocupado por las especificaciones C99. stdint.h declara tus macros intxx_t favoritos. __VA_ARGS__ está disponible. _Bool, _Complex y _Pragma no están implementados en el compilador de Microsoft Visual C++. Estoy bastante seguro de que% a de los campos en printf/scanf no se han implementado, aunque quizás VC2010 los maneje. snprintf está presente, pero tiene un guion bajo y una semántica ligeramente diferente.

Respuesta breve: La característica "más fácil" de un C99 es implementar sin cambiar las gramáticas del compilador o volver a conectar la biblioteca estándar, es más probable que VC++ la admita. Si hay un conflicto entre C99 y C++, espere que C++ gane.

Answer 4

tipo genérico funciones matemáticas de <tgmath.h> no necesariamente están ampliamente implementados, a pesar de que parecen estar siempre con GCC 4.2.1 en MacOS X 10.6.2.

Answer 5

restrict se convirtió en una palabra clave en C99. Esa es la implementación que invade el espacio de nombres de los usuarios. Si tiene un programa C89 válido que contiene la palabra restrict, debe cambiar su programa para que funcione con C99. En otras palabras: sin compatibilidad hacia atrás. Si iban a romper la compatibilidad con versiones anteriores, deberían haber eliminado gets del estándar primero.

Answer 6

Runtime sizeof es una pesadilla para los escritores de compiladores. Entonces, considero que es dañino.

Answer 7

glibc no implementa un C99 conforme realloc, por lo que realloc(ptr, 0) no es portátil.

http://sourceware.org/bugzilla/show_bug.cgi?id=12547