Quelles sont les caractéristiques C99 sont considérés comme nuisibles ou non pris en charge [fermé]

Question

J'écris habituellement du code C dans C89, maintenant quelques caractéristiques de C99 (comme intxx_t ou __VA_ARGS__ ou snprintf) sont très utiles, et peut être même vital.

Avant plus mes besoins de C89 à C99 je voulais savoir quelles fonctionnalités C99 ont été largement pris en charge et ceux qui ne sont pas pris en charge largement voire considéré comme néfaste.

Je sais que nous pourrions simplement vérifier notre soutien du compilateur cible, mais cela réduirait notre soutien beaucoup, et comme cela est un logiciel open source, je préfère avoir un support plus large.

Par exemple, nous utilisons le compilateur Solaris (de suncc) et gcc, mais il pourrait y avoir d'autres compilateur nous passerions de la route alors que nous pourrions garder la compatibilité avec très peu d'efforts.

Par exemple, je ne travaillé sur Windows, ni je sais rien sur compilateurs Windows, mais il serait bon de garder la compatibilité avec Windows.

Answer 1

Un certain nombre de caractéristiques C99 sont facultatifs, de sorte que leur absence est techniquement non conforme. Je ne vais pas faire la distinction ci-dessous.

• Hmm, gagnant n'a pas <stdint.h>, bien qu'il y ait une ouverture Version -source de stdint.h pour Microsoft . Même lorsque le fichier est mis en œuvre, la plupart des types individuels sont manquants.

• Prise en charge complexe et imaginaire est souvent manquant ou cassé.

• identificateurs étendus et caractères larges peuvent être des points de problème.

Voir cette liste des problèmes de fonctionnalité C99 dans gcc.

Answer 2

goto est encore considéré nuisibles.

---

D'une certaine façon, j'ai recueilli quatre vers le bas votes. J'ai présenté la déclaration ci-dessus pour ajouter la légèreté, et je suis seulement 30% au sérieux le concept derrière.

J'attends les votes sont en baisse de jeunes qui ne comprennent pas l'histoire des langages de programmation. Non chaque goto est mal, mais, par rapport à 100% du code spaghetti sans mélange que je travaille sur (millions de lignes de FORTRAN 66) -il est raisonnable et productive pour remplacer autant de déclarations de goto avec les déclarations structurées (for, while, do .. while, switch) que possible. Mais parfois, un goto est très bien quand il évite la complexité, comme les variables supplémentaires de drapeau pour sortir de plusieurs boucles imbriquées.

Answer 3

Eh bien, gcc va essentiellement être gcc, quel que soit l'OS de bureau que vous ciblez.

Visual C ++, étant principalement un compilateur C ++, est pas tout à fait aussi concernés par la spécification C99. stdint.h fait déclarer vos macros intxx_t préférées. __VA_ARGS__ est disponible. _Bool, _Complex et _Pragma ne sont pas mises en œuvre sur le compilateur Visual C ++ Microsoft. Je suis assez sûr% un champs printf / scanf n'ont pas été mises en œuvre, mais peut-être VC2010 les poignées. snprintf est présent, mais il a un underscore et une sémantique légèrement différente.

Réponse courte: Le plus « facile » une caractéristique de C99 est de mettre en œuvre sans modification du compilateur ou grammaires replumbing la bibliothèque standard, le VC ++ est plus susceptible de le soutenir. S'il y a un conflit entre C99 et C ++, C ++ attendre à gagner.

Answer 4

Runtime sizeof est un cauchemar des écrivains du compilateur. Je considère donc est nocif.

Answer 5

glibc ne met pas en œuvre une realloc C99 conforme, donc realloc(ptr, 0) est pas portable.

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

Answer 6

restrict est devenu un mot-clé dans C99. Ce empiètent sur la mise en œuvre de l'espace de noms des utilisateurs. Si vous avez un programme C89 valide qui contient le mot restrict, vous devez modifier votre programme pour le faire fonctionner avec C99. En d'autres termes: pas de compatibilité ascendante. S'ils allaient briser la compatibilité ascendante, ils devraient avoir gets retiré de la première norme.

Answer 7

Les fonctions mathématiques de type générique de <tgmath.h> ne sont pas nécessairement largement mises en œuvre, mais ils ne semblent fournir avec GCC 4.2.1 sur Mac OS X 10.6.2.