Quelle est la différence dans GCC entre -std = gnu ++ 0x et -std = c ++ 0x et laquelle doit être utilisée?

Question

J'ai des problèmes avec <stdint.h> lors de l'utilisation de -std=c++0x dans GCC 4.4.3 (pour Android):

 // using -std=c++0x
#include <stdint.h>
uint64_t value;  // error: 'uint64_t' does not name a type
 

Mais utiliser -std=gnu++0x fonctionne:

 // using -std=gnu++0x
#include <stdint.h>
uint64_t value;  // OK
 

<stdint.h> incompatible avec C ++ 0x?

Answer 1

Pour autant que je peux dire, je pense que cela pourrait faire valoir une mise en œuvre bug (ou en fait, depuis C++0x n'est pas publié, pas un bug en soi , mais une mise en œuvre incomplète de l'état actuel de la norme à venir).

Voici pourquoi, en se référant à n3225 pour le comportement attendu de l' -std=c++0x:

D. 7 dit

Chaque en-tête C, dont chacune a un nom de la forme nom.h, se comporte comme si chaque nom dans la norme bibliothèque de l'espace de noms par le correspondant cname en-tête est placé à l'intérieur de la espace de noms global portée

OK, c'est très facile. Qu'est - <cstdint> lieu dans la bibliothèque standard de l'espace de noms?

18.4.1:

typedef unsigned integer type uint64_t; // optional

Comment facultatif? 18.4.1/2:

L'en-tête définit toutes les fonctions, les types et les macros les mêmes que dans 7.18 le C standard

Drat. Quelle est la norme C dire? Prendre n1256, 7.18.1.1/3:

Ces types sont en option. Cependant, si une mise en œuvre fournit entier types avec des largeurs de 8, 16, 32, ou 64 bits, pas de rembourrage bits, et (pour la signé types) qui ont une en complément à deux de la représentation, il définit le correspondant typedef les noms de

Mais accroche toi, sûrement sur Android avec -std=c++0x GCC n' fournir une version 64 bits de type non signé et sans rembourrage bits: unsigned long long. Donc, <cstdint> est nécessaire pour fournir de l' std::uint64_t et, par conséquent stdint.h est nécessaire pour fournir de l' uint64_t en l'espace de noms global.

Allez, quelqu'un me dire pourquoi je suis mal :-) Une possibilité est que le C++0x se réfère à "la norme ISO/IEC 9899:1999 langages de Programmation - C", sans préciser une version. Peut-on vraiment que (un) 7.18.1.1/3 a été ajouté dans l'une des TCs, et aussi (b) de C++0x entend de référence de la norme d'origine à compter de 1999, les modifications apportées depuis lors? Je doute que ce soit le cas de figure, mais je n'ai pas l'original C99 sous la main pour vérifier (un) et je ne suis même pas sûr de la façon de le vérifier (b).

Edit: oh, pour lequel doit être utilisé -std=c++0x n'est pas vraiment une stricte conforme aux normes mode encore, puisqu'il n'y a pas une norme stricte encore. Et même s'il y a une norme, gcc 4.4.3 n'est certainement pas fini, d'une mise en œuvre. Donc je ne vois pas grand besoin de l'utiliser si -std=gnu++0x est en réalité plus complète, au moins dans ce respect pour votre combinaison de version de gcc et de la plate-forme.

Toutefois, gnu++0x permettra à d'autres extensions GNU, que vous ne voudriez pas votre code à utiliser. Si vous êtes visant à écrire portable C++0x, finalement, vous voulez passer à -std=c++0x. Mais je ne pense pas que GCC 4.4 ou de toute autre C++0x mise en œuvre en cours est assez complet mais pour qu'il soit pratique à l'écriture de code du projet de norme, telle que l'on pourrait dire avec un visage impassible "je suis de programmation C++0x, et c'est seulement en 2011!". Donc, je dirais, utilisez celle que l'on travaille, et de comprendre que, quel que soit celui que vous utilisez maintenant, vous aurez probablement basculer -std=c++11 , éventuellement, de toute façon.