iec - estandar c99
Qué características de C99 se consideran dañinas o no compatibles (7)
Normalmente escribo el 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 cumplir con 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 verificar nuestra compatibilidad con el compilador 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 los compiladores de Windows, pero sería bueno mantener la compatibilidad de Windows.
glibc no implementa un realloc conforme a realloc , por lo que realloc(ptr, 0) no es portátil.
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 la especificación 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 corta: cuanto más fácil es implementar una función C99 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.
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, win no tiene
<stdint.h>, aunque hay una versión de código abierto de stdint.h para Microsoft . Incluso cuando se implementa el archivo, faltan muchos de los tipos individuales.El soporte complejo e imaginario a menudo falta o está roto.
Los identificadores ampliados y los caracteres anchos pueden ser puntos problemáticos.
Consulte esta lista de problemas de características C99 en gcc.
Las funciones de matemáticas genéricas de tipo de <tgmath.h> no se implementan ampliamente, aunque sí parecen estar provistas con GCC 4.2.1 en MacOS X 10.6.2.
restrict 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, primero deberían haber eliminado el estándar.
El tamaño de tiempo de ejecución es una pesadilla para los escritores de compiladores. Entonces, considero que es dañino.
goto todavía se considera dañino .
De alguna manera, he recolectado cuatro votos abajo. 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 bajos provengan de jóvenes que no entienden la historia de los lenguajes de programación. No todos los goto son malos, pero en comparación con el código de spaghetti 100% no adulterado en el que he trabajado (millones de líneas de FORTRAN 66), es razonable y productivo reemplazar tantas declaraciones goto con declaraciones estructuradas ( for , while , do .. while , switch ) como sea posible. Pero a veces un goto está bien cuando evita la complejidad, como las variables de indicador adicionales para salir de múltiples bucles anidados.