2010-06-29 4 views
3

Quelle est la différence entre <cstdint> et <tr1/cstdint>? (à part que l'on place les choses dans l'espace de noms std:: et l'autre dans std::tr1::)différence entre cstdint et tr1/cstdint

Comme ce matériel n'est pas encore standard, je suppose que c'est spécifique au compilateur, donc je parle de gcc. Pour compiler avec le non-tr1 je dois compiler avec -std=c++0x, mais il n'y a pas une telle restriction en utilisant tr1.

Est-ce que la réponse est peut-être qu'il n'y en a pas mais que vous ne pouvez pas faire le tour en ajoutant des choses à std:: à moins qu'il y ait, bien, standard. Donc, jusqu'à ce que C++ 0x soit standardisé, une erreur doit être émise en utilisant <cstdint> mais vous n'avez pas à vous inquiéter en ajoutant à l'espace de noms tr1::, ce qui ne prétend pas que les choses soient standard? Ou y a-t-il plus à cela?

Merci.

p.s - Si vous lisez « std » en standard, comme je le fais, je vous présente mes excuses pour l'utilisation excessive du mot dans cette Q.

Répondre

3

Au moins autant que je sache, il n'y avait aucune intention de changer <cstdint> entre TR1 et C++ 0x. Il n'y a pas besoin de #include ing <cstdint> pour entraîner une erreur si - officiellement, ce n'est rien de plus ou de moins qu'un comportement indéfini. Une implémentation est autorisée à spécifier un comportement exact, et dans ce cas, c'est le cas.

+0

Ah oui, désolé, ne voulait pas dire que le compilateur était obligé d'erreur lors de l'ajout de 'std ::', mais c'est en quelque sorte ce que j'ai dit n'est pas si cher pour effacer l'ambiguïté. Voulez-vous dire que l'ajout de 'std ::' cause un comportement indéfini?Je ne m'en suis pas rendu compte, je pensais juste que c'était une très mauvaise forme. bon à savoir. Aussi, en lisant entre les lignes, puis-je supposer que les en-têtes TR1 ne changeront pas maintenant, alors que les en-têtes C++ 0x peuvent évidemment (et le seront probablement). – tjm

+0

Les en-têtes TR1 sont ce qu'ils sont et ne changeront pas. À ce stade, je serais plutôt surpris de voir des changements significatifs dans les en-têtes C++ 0x, bien qu'ils aient déjà produit le "draft du comité final" et fermé la période officielle de commentaires pour C++ 0x, donc À ce stade, il s'agit surtout de répondre à tous les commentaires officiels et d'effectuer le nettoyage final du libellé, mais pour l'essentiel, l'intention du document doit rester la même. Il s'agit simplement de s'assurer prévu. –

+0

Merci, ça éclaircit vraiment les choses pour moi. – tjm

3

Je pense que vous l'avez. Sur mon système, ils sont très similaires, mais avec une logique macro différente. Par exemple, /usr/include/c++/4.4/tr1/cstdint a:

# define _GLIBCXX_BEGIN_NAMESPACE_TR1 namespace tr1 { 
# define _GLIBCXX_END_NAMESPACE_TR1 } 
# define _GLIBCXX_TR1 tr1:: 

mais/usr/include/c++/4.4/cstdint a:

# define _GLIBCXX_BEGIN_NAMESPACE_TR1 
# define _GLIBCXX_END_NAMESPACE_TR1 
# define _GLIBCXX_TR1 

Donc, s'il est inclus comme étant <cstdint> l'espace de noms TR1 est simplement défini dans l'oubli.

+0

merci beaucoup, comme je m'attendais alors. bon de l'avoir confirmé. – tjm

2

<tr1/cstdint> est défini, comme son nom l'indique, dans TR1, tandis que <cstdint> est défini dans c++0x.

À partir du manuel gcc, -std=c++0x est requis pour activer les fonctions expérimentales susceptibles d'être incluses dans C++ 0x. Cependant, <tr1/cstdint> est défini dans TR1, et non c++0x, donc -std=c++0x n'est pas nécessaire.

Ce qui suit est le manuel de gcc pour -std=c++0x pour votre référence.

Le brouillon de travail du prochain standard ISO C++ 0x. Cette option permet d'inclure des fonctionnalités expérimentales dans C++ 0x. Le brouillon de travail change constamment, et toute fonctionnalité activée par cet indicateur peut être supprimée des futures versions de GCC si elle ne fait pas partie de la norme C++ 0x .