De temps en temps, dans mes lectures je trouve __gnu_cxx::hash_map.. au lieu
de std::hash_map.. Pour quel raison utilise t'on __gnu_cxx:: (cela ma semble
equivalent).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
kanze
Bruno CAUSSE wrote:
De temps en temps, dans mes lectures je trouve __gnu_cxx::hash_map.. au lieu de std::hash_map.. Pour quel raison utilise t'on __gnu_cxx:: (cela ma semble equivalent).
On utilise ce que fournit le compilateur où on se trouve.
Il n'y a pas de classe hash_map dans le C++ standard ; elle est arrivée trop tard pour la dernière tournée de normalisation. La plupart des compilateurs l'ont cependant fournie, en std::, mais de façon légèrement différente. Ensuite, on s'en est rendu compte que mettre des extensions de ce genre dans std:: n'était pas une bonne idée. G++ l'a déplacée dans __gnu_cxx (où, je crois que tout le monde en est d'accord maintenant) il aurait dû être dès le début. D'autres n'ont pas ôsé casser du code existant chez leurs clients, et l'ont laissée dans std::.
Depuis, la classe a été normalisée sous le nom std::unordered_map. Je ne sais pas le status exact, en révanche ; si unordered_map fait partie d'un TR, ou s'il est simplement prévu qu'il fasse partie de la prochaine version de la norme.
En attendant, je te conseille d'utiliser ta propre ChezMoi::HashMap (ou tout autre nom). Avec std::hash_map, __gnu_cxx::hash_map, ou tr1::unordered_map comme implémentation, selon la plateforme. Ou simplement de se contenter de std::map, tant qu'il n'y a pas de dizaines de milliers d'éléments.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Bruno CAUSSE wrote:
De temps en temps, dans mes lectures je trouve
__gnu_cxx::hash_map.. au lieu de std::hash_map.. Pour quel
raison utilise t'on __gnu_cxx:: (cela ma semble equivalent).
On utilise ce que fournit le compilateur où on se trouve.
Il n'y a pas de classe hash_map dans le C++ standard ; elle est
arrivée trop tard pour la dernière tournée de normalisation. La
plupart des compilateurs l'ont cependant fournie, en std::, mais
de façon légèrement différente. Ensuite, on s'en est rendu
compte que mettre des extensions de ce genre dans std:: n'était
pas une bonne idée. G++ l'a déplacée dans __gnu_cxx (où, je
crois que tout le monde en est d'accord maintenant) il aurait dû
être dès le début. D'autres n'ont pas ôsé casser du code
existant chez leurs clients, et l'ont laissée dans std::.
Depuis, la classe a été normalisée sous le nom
std::unordered_map. Je ne sais pas le status exact, en
révanche ; si unordered_map fait partie d'un TR, ou s'il est
simplement prévu qu'il fasse partie de la prochaine version de
la norme.
En attendant, je te conseille d'utiliser ta propre
ChezMoi::HashMap (ou tout autre nom). Avec std::hash_map,
__gnu_cxx::hash_map, ou tr1::unordered_map comme implémentation,
selon la plateforme. Ou simplement de se contenter de std::map,
tant qu'il n'y a pas de dizaines de milliers d'éléments.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
De temps en temps, dans mes lectures je trouve __gnu_cxx::hash_map.. au lieu de std::hash_map.. Pour quel raison utilise t'on __gnu_cxx:: (cela ma semble equivalent).
On utilise ce que fournit le compilateur où on se trouve.
Il n'y a pas de classe hash_map dans le C++ standard ; elle est arrivée trop tard pour la dernière tournée de normalisation. La plupart des compilateurs l'ont cependant fournie, en std::, mais de façon légèrement différente. Ensuite, on s'en est rendu compte que mettre des extensions de ce genre dans std:: n'était pas une bonne idée. G++ l'a déplacée dans __gnu_cxx (où, je crois que tout le monde en est d'accord maintenant) il aurait dû être dès le début. D'autres n'ont pas ôsé casser du code existant chez leurs clients, et l'ont laissée dans std::.
Depuis, la classe a été normalisée sous le nom std::unordered_map. Je ne sais pas le status exact, en révanche ; si unordered_map fait partie d'un TR, ou s'il est simplement prévu qu'il fasse partie de la prochaine version de la norme.
En attendant, je te conseille d'utiliser ta propre ChezMoi::HashMap (ou tout autre nom). Avec std::hash_map, __gnu_cxx::hash_map, ou tr1::unordered_map comme implémentation, selon la plateforme. Ou simplement de se contenter de std::map, tant qu'il n'y a pas de dizaines de milliers d'éléments.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis
"kanze" writes:
[...]
| G++ l'a déplacée dans __gnu_cxx (où, je | crois que tout le monde en est d'accord maintenant) il aurait dû | être dès le début. D'autres n'ont pas ôsé casser du code | existant chez leurs clients, et l'ont laissée dans std::. | | Depuis, la classe a été normalisée sous le nom | std::unordered_map.
std::tr1::unordered_map ^^^
et ce n'est pas encore normalisé (au sens norme ISO), mais effectivement un document officiel ISO "TR" (Technical Report) -- en gros si un vendeur veut fournir une table de hashage, c'est comme cela que le comité recommande.
À noter que hash_map n'a pas été retenu parce que certains, notamment l'inénarrable MS, ont dit qu'ils ont déjà mis un truc de ce nom dans std:: (une erreur kolossale.) Donc, on s'est coltiné le curieux « unordered_map. » Aux dernières discussions (moins de quelques mois), il a été suggéré que std::hash_map n'existera plus chez MS -- mais le comité ne changera quand même pas unordered_map à hash_map.
À noter également que GCC n'a pas été le seul à corriger l'erreur assez rapidement, d'autres comme CodeWarrior ou Rogue Wave l'ont également corrigée.
-- Gaby
"kanze" <kanze@gabi-soft.fr> writes:
[...]
| G++ l'a déplacée dans __gnu_cxx (où, je
| crois que tout le monde en est d'accord maintenant) il aurait dû
| être dès le début. D'autres n'ont pas ôsé casser du code
| existant chez leurs clients, et l'ont laissée dans std::.
|
| Depuis, la classe a été normalisée sous le nom
| std::unordered_map.
std::tr1::unordered_map
^^^
et ce n'est pas encore normalisé (au sens norme ISO), mais
effectivement un document officiel ISO "TR" (Technical Report) -- en
gros si un vendeur veut fournir une table de hashage, c'est comme
cela que le comité recommande.
À noter que hash_map n'a pas été retenu parce que certains, notamment
l'inénarrable MS, ont dit qu'ils ont déjà mis un truc de ce nom dans
std:: (une erreur kolossale.) Donc, on s'est coltiné le curieux
« unordered_map. » Aux dernières discussions (moins de quelques
mois), il a été suggéré que std::hash_map n'existera plus chez MS --
mais le comité ne changera quand même pas unordered_map à hash_map.
À noter également que GCC n'a pas été le seul à corriger l'erreur assez
rapidement, d'autres comme CodeWarrior ou Rogue Wave l'ont également
corrigée.
| G++ l'a déplacée dans __gnu_cxx (où, je | crois que tout le monde en est d'accord maintenant) il aurait dû | être dès le début. D'autres n'ont pas ôsé casser du code | existant chez leurs clients, et l'ont laissée dans std::. | | Depuis, la classe a été normalisée sous le nom | std::unordered_map.
std::tr1::unordered_map ^^^
et ce n'est pas encore normalisé (au sens norme ISO), mais effectivement un document officiel ISO "TR" (Technical Report) -- en gros si un vendeur veut fournir une table de hashage, c'est comme cela que le comité recommande.
À noter que hash_map n'a pas été retenu parce que certains, notamment l'inénarrable MS, ont dit qu'ils ont déjà mis un truc de ce nom dans std:: (une erreur kolossale.) Donc, on s'est coltiné le curieux « unordered_map. » Aux dernières discussions (moins de quelques mois), il a été suggéré que std::hash_map n'existera plus chez MS -- mais le comité ne changera quand même pas unordered_map à hash_map.
À noter également que GCC n'a pas été le seul à corriger l'erreur assez rapidement, d'autres comme CodeWarrior ou Rogue Wave l'ont également corrigée.
