Avant d'utiliser std::tr1::unordered (je ne trouve pas de bons docs, sur ce
coup Google n'est pas mon ami), j'ai regardé du coté standard std::hash_map
Je trouve bizarre d'avoir pour cle un objet (dans mon cas un bitboard 128
bits) et de fournir une fonction de hashage qui retourne un size_t ( typedef
unsigned int size_t;) soit 32 bits. Ai je loupé qque chose?
ps: juste pour info pourquoi faut il utiliser unordered avec gcc > 4 ?
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
loufoque
Je trouve bizarre d'avoir pour cle un objet (dans mon cas un bitboard 128 bits) et de fournir une fonction de hashage qui retourne un size_t ( typedef unsigned int size_t;) soit 32 bits. Ai je loupé qque chose?
En quoi c'est bizarre ?
Je trouve bizarre d'avoir pour cle un objet (dans mon cas un bitboard 128
bits) et de fournir une fonction de hashage qui retourne un size_t ( typedef
unsigned int size_t;) soit 32 bits. Ai je loupé qque chose?
Je trouve bizarre d'avoir pour cle un objet (dans mon cas un bitboard 128 bits) et de fournir une fonction de hashage qui retourne un size_t ( typedef unsigned int size_t;) soit 32 bits. Ai je loupé qque chose?
En quoi c'est bizarre ?
pasde.hcyrano.spam
loufoque wrote:
Je trouve bizarre d'avoir pour cle un objet (dans mon cas un bitboard 128 bits) et de fournir une fonction de hashage qui retourne un size_t ( typedef unsigned int size_t;) soit 32 bits. Ai je loupé qque chose?
En quoi c'est bizarre ?
si j'ai bien compri une hash_map est un container assosiatif (Key, Data) ou chaque cle est unique.
hash_map<Key, Data, HashFcn, EqualKey, Alloc>
HashFcn est une fonction de hashage qui prend la cle en input et retourne un size_t (32 bits)
EqualKey est une fonction qui compare l'egalité de 2 cles
si la fonction EqualKey ne semble evidente, a quoi sert sur ce type de container HashFcn (a accelerer les recherches? on compare les hashs (2 32 bits) avant de comparer les cles plus complexes)
puis je utiliser hash_map avec gcc > 4?
ton lien http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1456.html ne repond pas ce soir :( -- Bruno Causse http://perso.wanadoo.fr/othello
loufoque <loufoque@remove.gmail.com> wrote:
Je trouve bizarre d'avoir pour cle un objet (dans mon cas un bitboard 128
bits) et de fournir une fonction de hashage qui retourne un size_t ( typedef
unsigned int size_t;) soit 32 bits. Ai je loupé qque chose?
En quoi c'est bizarre ?
si j'ai bien compri une hash_map est un container assosiatif (Key, Data)
ou chaque cle est unique.
hash_map<Key, Data, HashFcn, EqualKey, Alloc>
HashFcn est une fonction de hashage qui prend la cle en input et
retourne un size_t (32 bits)
EqualKey est une fonction qui compare l'egalité de 2 cles
si la fonction EqualKey ne semble evidente, a quoi sert sur ce type de
container HashFcn (a accelerer les recherches? on compare les hashs (2
32 bits) avant de comparer les cles plus complexes)
puis je utiliser hash_map avec gcc > 4?
ton lien
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1456.html
ne repond pas ce soir :(
--
Bruno Causse
http://perso.wanadoo.fr/othello
Je trouve bizarre d'avoir pour cle un objet (dans mon cas un bitboard 128 bits) et de fournir une fonction de hashage qui retourne un size_t ( typedef unsigned int size_t;) soit 32 bits. Ai je loupé qque chose?
En quoi c'est bizarre ?
si j'ai bien compri une hash_map est un container assosiatif (Key, Data) ou chaque cle est unique.
hash_map<Key, Data, HashFcn, EqualKey, Alloc>
HashFcn est une fonction de hashage qui prend la cle en input et retourne un size_t (32 bits)
EqualKey est une fonction qui compare l'egalité de 2 cles
si la fonction EqualKey ne semble evidente, a quoi sert sur ce type de container HashFcn (a accelerer les recherches? on compare les hashs (2 32 bits) avant de comparer les cles plus complexes)
puis je utiliser hash_map avec gcc > 4?
ton lien http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1456.html ne repond pas ce soir :( -- Bruno Causse http://perso.wanadoo.fr/othello
Loïc Joly
loufoque wrote:
Je trouve bizarre d'avoir pour cle un objet (dans mon cas un bitboard 128 bits) et de fournir une fonction de hashage qui retourne un size_t ( typedef unsigned int size_t;) soit 32 bits. Ai je loupé qque chose?
[...]
si la fonction EqualKey ne semble evidente, a quoi sert sur ce type de container HashFcn (a accelerer les recherches? on compare les hashs (2 32 bits) avant de comparer les cles plus complexes)
C'est tout l'intérêt d'une table de hash... Regarde de la doc sur les structures classiques de donnés pour plus d'infos. Si tu ne veux pas t'embêter avec une fonction de hachage, utilise std::map. Dans certains cas, ce sera plus rapide, dans d'autres plus lent.
puis je utiliser hash_map avec gcc > 4?
hash_map n'est pas standard. Quand on a voulu ajouter ce genre de fonction en C++, il existait déjà plusieurs hash_map différents que divers compilateurs avaient induement placé dans std. Pour ne pas casser trop de code, il a donc été décidé que le standard se baserait sur un nom moins courant, donc cassant moins de code, bien que moins expressif. Je pense que gcc a adopté cet ajout au standard. Je ne sais pas s'ils gardent une ancienne version pour compatibilité.
ton lien http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1456.html ne repond pas ce soir :(
Leur serveur a un problème. Tu peux utiliser le backup : http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1456.html
-- Loïc
loufoque <loufoque@remove.gmail.com> wrote:
Je trouve bizarre d'avoir pour cle un objet (dans mon cas un bitboard 128
bits) et de fournir une fonction de hashage qui retourne un size_t ( typedef
unsigned int size_t;) soit 32 bits. Ai je loupé qque chose?
[...]
si la fonction EqualKey ne semble evidente, a quoi sert sur ce type de
container HashFcn (a accelerer les recherches? on compare les hashs (2
32 bits) avant de comparer les cles plus complexes)
C'est tout l'intérêt d'une table de hash... Regarde de la doc sur les
structures classiques de donnés pour plus d'infos. Si tu ne veux pas
t'embêter avec une fonction de hachage, utilise std::map. Dans certains
cas, ce sera plus rapide, dans d'autres plus lent.
puis je utiliser hash_map avec gcc > 4?
hash_map n'est pas standard. Quand on a voulu ajouter ce genre de
fonction en C++, il existait déjà plusieurs hash_map différents que
divers compilateurs avaient induement placé dans std. Pour ne pas casser
trop de code, il a donc été décidé que le standard se baserait sur un
nom moins courant, donc cassant moins de code, bien que moins expressif.
Je pense que gcc a adopté cet ajout au standard. Je ne sais pas s'ils
gardent une ancienne version pour compatibilité.
ton lien
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1456.html
ne repond pas ce soir :(
Leur serveur a un problème. Tu peux utiliser le backup :
http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1456.html
Je trouve bizarre d'avoir pour cle un objet (dans mon cas un bitboard 128 bits) et de fournir une fonction de hashage qui retourne un size_t ( typedef unsigned int size_t;) soit 32 bits. Ai je loupé qque chose?
[...]
si la fonction EqualKey ne semble evidente, a quoi sert sur ce type de container HashFcn (a accelerer les recherches? on compare les hashs (2 32 bits) avant de comparer les cles plus complexes)
C'est tout l'intérêt d'une table de hash... Regarde de la doc sur les structures classiques de donnés pour plus d'infos. Si tu ne veux pas t'embêter avec une fonction de hachage, utilise std::map. Dans certains cas, ce sera plus rapide, dans d'autres plus lent.
puis je utiliser hash_map avec gcc > 4?
hash_map n'est pas standard. Quand on a voulu ajouter ce genre de fonction en C++, il existait déjà plusieurs hash_map différents que divers compilateurs avaient induement placé dans std. Pour ne pas casser trop de code, il a donc été décidé que le standard se baserait sur un nom moins courant, donc cassant moins de code, bien que moins expressif. Je pense que gcc a adopté cet ajout au standard. Je ne sais pas s'ils gardent une ancienne version pour compatibilité.
ton lien http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1456.html ne repond pas ce soir :(
Leur serveur a un problème. Tu peux utiliser le backup : http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1456.html
-- Loïc
fabien.chene
Loïc Joly writes:
hash_map n'est pas standard. Quand on a voulu ajouter ce genre de fonction en C++, il existait déjà plusieurs hash_map différents que divers compilateurs avaient induement placé dans std. Pour ne pas casser trop de code, il a donc été décidé que le standard se baserait sur un nom moins courant, donc cassant moins de code, bien que moins expressif.
Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir lu un article -- très probablement sur le site du WG21 -- dans lequel était expliqué le pourquoi du nom «unordered_map» en lieu et place de «hash_map».
Ton explication (qui coïncide je crois avec celle qu'avait founie ici Gaby), est différente de ce que j'avais lu. Un des arguments en faveur du nom «unordered_map», était que ce nom avait le mérite d'insister sur le fait que les paires clés-valeurs n'était pas ordonnées.
Il y avait d'autres arguments. De là à justifer un nom différent de celui auquel tout le monde s'attendait ? J'y avais cru sur le coup.
hash_map n'est pas standard. Quand on a voulu ajouter ce genre de
fonction en C++, il existait déjà plusieurs hash_map différents que
divers compilateurs avaient induement placé dans std. Pour ne pas
casser trop de code, il a donc été décidé que le standard se baserait
sur un nom moins courant, donc cassant moins de code, bien que moins
expressif.
Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir
lu un article -- très probablement sur le site du WG21 -- dans lequel
était expliqué le pourquoi du nom «unordered_map» en lieu et place de
«hash_map».
Ton explication (qui coïncide je crois avec celle qu'avait founie ici
Gaby), est différente de ce que j'avais lu. Un des arguments en faveur
du nom «unordered_map», était que ce nom avait le mérite d'insister
sur le fait que les paires clés-valeurs n'était pas ordonnées.
Il y avait d'autres arguments. De là à justifer un nom différent de
celui auquel tout le monde s'attendait ? J'y avais cru sur le coup.
hash_map n'est pas standard. Quand on a voulu ajouter ce genre de fonction en C++, il existait déjà plusieurs hash_map différents que divers compilateurs avaient induement placé dans std. Pour ne pas casser trop de code, il a donc été décidé que le standard se baserait sur un nom moins courant, donc cassant moins de code, bien que moins expressif.
Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir lu un article -- très probablement sur le site du WG21 -- dans lequel était expliqué le pourquoi du nom «unordered_map» en lieu et place de «hash_map».
Ton explication (qui coïncide je crois avec celle qu'avait founie ici Gaby), est différente de ce que j'avais lu. Un des arguments en faveur du nom «unordered_map», était que ce nom avait le mérite d'insister sur le fait que les paires clés-valeurs n'était pas ordonnées.
Il y avait d'autres arguments. De là à justifer un nom différent de celui auquel tout le monde s'attendait ? J'y avais cru sur le coup.
-- Fab
Loïc Joly
Loïc Joly writes:
Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir lu un article -- très probablement sur le site du WG21 -- dans lequel était expliqué le pourquoi du nom «unordered_map» en lieu et place de «hash_map».
Ton explication (qui coïncide je crois avec celle qu'avait founie ici Gaby), est différente de ce que j'avais lu. Un des arguments en faveur du nom «unordered_map», était que ce nom avait le mérite d'insister sur le fait que les paires clés-valeurs n'était pas ordonnées.
L'un n'empêche pas l'autre. Une fois hash_map indisponible, il a bien fallu choisir un remplaçant, et justifier ce choix. Je n'en pense pas moins que hash_map aurait été plus naturel pour tous.
Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir
lu un article -- très probablement sur le site du WG21 -- dans lequel
était expliqué le pourquoi du nom «unordered_map» en lieu et place de
«hash_map».
Ton explication (qui coïncide je crois avec celle qu'avait founie ici
Gaby), est différente de ce que j'avais lu. Un des arguments en faveur
du nom «unordered_map», était que ce nom avait le mérite d'insister
sur le fait que les paires clés-valeurs n'était pas ordonnées.
L'un n'empêche pas l'autre. Une fois hash_map indisponible, il a bien
fallu choisir un remplaçant, et justifier ce choix. Je n'en pense pas
moins que hash_map aurait été plus naturel pour tous.
Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir lu un article -- très probablement sur le site du WG21 -- dans lequel était expliqué le pourquoi du nom «unordered_map» en lieu et place de «hash_map».
Ton explication (qui coïncide je crois avec celle qu'avait founie ici Gaby), est différente de ce que j'avais lu. Un des arguments en faveur du nom «unordered_map», était que ce nom avait le mérite d'insister sur le fait que les paires clés-valeurs n'était pas ordonnées.
L'un n'empêche pas l'autre. Une fois hash_map indisponible, il a bien fallu choisir un remplaçant, et justifier ce choix. Je n'en pense pas moins que hash_map aurait été plus naturel pour tous.
-- Loïc
Gabriel Dos Reis
(Fabien Chêne) writes:
| Loïc Joly writes: | | > hash_map n'est pas standard. Quand on a voulu ajouter ce genre de | > fonction en C++, il existait déjà plusieurs hash_map différents que | > divers compilateurs avaient induement placé dans std. Pour ne pas | > casser trop de code, il a donc été décidé que le standard se baserait | > sur un nom moins courant, donc cassant moins de code, bien que moins | > expressif. | | Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir | lu un article -- très probablement sur le site du WG21 -- dans lequel | était expliqué le pourquoi du nom «unordered_map» en lieu et place de | «hash_map». | | Ton explication (qui coïncide je crois avec celle qu'avait founie ici | Gaby), est différente de ce que j'avais lu. Un des arguments en faveur | du nom «unordered_map», était que ce nom avait le mérite d'insister | sur le fait que les paires clés-valeurs n'était pas ordonnées.
Ça, c'est le genre de bullshit qu'on vend aux électeurs pendant les périodes de campagnes. C'est une raison trouvée après coût. J'imagine mal un document officiel du comité ISO C++ dire qu'ils ont pas pris le nom évident parce que MS s'est mal conduit.
La vraie raison est celle donnée par Loïc.
-- Gaby
fabien.chene@gmail.com (Fabien Chêne) writes:
| Loïc Joly <loic.actarus.joly@numericable.fr> writes:
|
| > hash_map n'est pas standard. Quand on a voulu ajouter ce genre de
| > fonction en C++, il existait déjà plusieurs hash_map différents que
| > divers compilateurs avaient induement placé dans std. Pour ne pas
| > casser trop de code, il a donc été décidé que le standard se baserait
| > sur un nom moins courant, donc cassant moins de code, bien que moins
| > expressif.
|
| Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir
| lu un article -- très probablement sur le site du WG21 -- dans lequel
| était expliqué le pourquoi du nom «unordered_map» en lieu et place de
| «hash_map».
|
| Ton explication (qui coïncide je crois avec celle qu'avait founie ici
| Gaby), est différente de ce que j'avais lu. Un des arguments en faveur
| du nom «unordered_map», était que ce nom avait le mérite d'insister
| sur le fait que les paires clés-valeurs n'était pas ordonnées.
Ça, c'est le genre de bullshit qu'on vend aux électeurs pendant les
périodes de campagnes. C'est une raison trouvée après coût.
J'imagine mal un document officiel du comité ISO C++ dire qu'ils ont
pas pris le nom évident parce que MS s'est mal conduit.
| Loïc Joly writes: | | > hash_map n'est pas standard. Quand on a voulu ajouter ce genre de | > fonction en C++, il existait déjà plusieurs hash_map différents que | > divers compilateurs avaient induement placé dans std. Pour ne pas | > casser trop de code, il a donc été décidé que le standard se baserait | > sur un nom moins courant, donc cassant moins de code, bien que moins | > expressif. | | Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir | lu un article -- très probablement sur le site du WG21 -- dans lequel | était expliqué le pourquoi du nom «unordered_map» en lieu et place de | «hash_map». | | Ton explication (qui coïncide je crois avec celle qu'avait founie ici | Gaby), est différente de ce que j'avais lu. Un des arguments en faveur | du nom «unordered_map», était que ce nom avait le mérite d'insister | sur le fait que les paires clés-valeurs n'était pas ordonnées.
Ça, c'est le genre de bullshit qu'on vend aux électeurs pendant les périodes de campagnes. C'est une raison trouvée après coût. J'imagine mal un document officiel du comité ISO C++ dire qu'ils ont pas pris le nom évident parce que MS s'est mal conduit.
La vraie raison est celle donnée par Loïc.
-- Gaby
loufoque
Ton explication (qui coïncide je crois avec celle qu'avait founie ici Gaby), est différente de ce que j'avais lu. Un des arguments en faveur du nom «unordered_map», était que ce nom avait le mérite d'insister sur le fait que les paires clés-valeurs n'était pas ordonnées.
C'est pour ça qu'il y a des références explicites au hachage dans l'interface de unordered_* ?
Ton explication (qui coïncide je crois avec celle qu'avait founie ici
Gaby), est différente de ce que j'avais lu. Un des arguments en faveur
du nom «unordered_map», était que ce nom avait le mérite d'insister
sur le fait que les paires clés-valeurs n'était pas ordonnées.
C'est pour ça qu'il y a des références explicites au hachage dans
l'interface de unordered_* ?
Ton explication (qui coïncide je crois avec celle qu'avait founie ici Gaby), est différente de ce que j'avais lu. Un des arguments en faveur du nom «unordered_map», était que ce nom avait le mérite d'insister sur le fait que les paires clés-valeurs n'était pas ordonnées.
C'est pour ça qu'il y a des références explicites au hachage dans l'interface de unordered_* ?
kanze
Gabriel Dos Reis wrote:
(Fabien Chêne) writes:
| Loïc Joly writes:
| > hash_map n'est pas standard. Quand on a voulu ajouter ce genre de | > fonction en C++, il existait déjà plusieurs hash_map différents que | > divers compilateurs avaient induement placé dans std. Pour ne pas | > casser trop de code, il a donc été décidé que le standard se baserait | > sur un nom moins courant, donc cassant moins de code, bien que moins | > expressif.
| Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir | lu un article -- très probablement sur le site du WG21 -- dans lequel | était expliqué le pourquoi du nom «unordered_map» en lieu et pl ace de | «hash_map».
| Ton explication (qui coïncide je crois avec celle qu'avait founie ici | Gaby), est différente de ce que j'avais lu. Un des arguments en faveur | du nom «unordered_map», était que ce nom avait le mérite d'insi ster | sur le fait que les paires clés-valeurs n'était pas ordonnées.
Ça, c'est le genre de bullshit qu'on vend aux électeurs pendant les périodes de campagnes. C'est une raison trouvée après coût. J'imagine mal un document officiel du comité ISO C++ dire qu'ils ont pas pris le nom évident parce que MS s'est mal conduit.
Pas que Microsoft. Les premières versions de hash_map étaient prèsque toutes dans std::. Quand on s'en est rendu compte que ce n'était pas une bonne idée, g++ l'a déplacé dans un espace référentiel à part, mais il était à peu près le seul, je crois. (En tout cas, dans la version de la STLport livrée avec Sun CC, c'est aussi dans std.)
Le problème n'est pas simple. Une fois que tu l'as livré en std::, changer casse du code existant chez tes clients. Ce que ne veut faire aucun fournisseur responsable non plus. Alors, le bon choix dépend de beaucoup de paramètres. (Ou plutôt, il n'y a pas de bon choix : quoique tu fasses, ce n'est pas bon pour certains.)
Ensuite... Je crois qu'il y a quand même un concensus que le bon nom pour ces classes, c'est simplement set et map, et que les classes existantes doivent s'appeler ordered_set et ordered_map. Mais là aussi, c'est une option qui n'existe plus. (Au moins que... On garde le contenu de std tel qu'il est, sans le moindre changement, et on définit une bibliothèque nouvelle, std2::, par exemple, ou std0x::, dans laquelle on met tout ce qui est nouveau. Et éventuellement, on y copie tout ce qu'on veut garder inchangé.)
-- James Kanze (GABI Software) email: 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
| > hash_map n'est pas standard. Quand on a voulu ajouter ce genre de
| > fonction en C++, il existait déjà plusieurs hash_map différents que
| > divers compilateurs avaient induement placé dans std. Pour ne pas
| > casser trop de code, il a donc été décidé que le standard se baserait
| > sur un nom moins courant, donc cassant moins de code, bien que moins
| > expressif.
| Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir
| lu un article -- très probablement sur le site du WG21 -- dans lequel
| était expliqué le pourquoi du nom «unordered_map» en lieu et pl ace de
| «hash_map».
| Ton explication (qui coïncide je crois avec celle qu'avait founie ici
| Gaby), est différente de ce que j'avais lu. Un des arguments en faveur
| du nom «unordered_map», était que ce nom avait le mérite d'insi ster
| sur le fait que les paires clés-valeurs n'était pas ordonnées.
Ça, c'est le genre de bullshit qu'on vend aux électeurs pendant les
périodes de campagnes. C'est une raison trouvée après coût.
J'imagine mal un document officiel du comité ISO C++ dire qu'ils ont
pas pris le nom évident parce que MS s'est mal conduit.
Pas que Microsoft. Les premières versions de hash_map étaient
prèsque toutes dans std::. Quand on s'en est rendu compte que ce
n'était pas une bonne idée, g++ l'a déplacé dans un espace
référentiel à part, mais il était à peu près le seul, je crois.
(En tout cas, dans la version de la STLport livrée avec Sun CC,
c'est aussi dans std.)
Le problème n'est pas simple. Une fois que tu l'as livré en
std::, changer casse du code existant chez tes clients. Ce que
ne veut faire aucun fournisseur responsable non plus. Alors, le
bon choix dépend de beaucoup de paramètres. (Ou plutôt, il n'y a
pas de bon choix : quoique tu fasses, ce n'est pas bon pour
certains.)
Ensuite... Je crois qu'il y a quand même un concensus que le bon
nom pour ces classes, c'est simplement set et map, et que les
classes existantes doivent s'appeler ordered_set et ordered_map.
Mais là aussi, c'est une option qui n'existe plus. (Au moins
que... On garde le contenu de std tel qu'il est, sans le moindre
changement, et on définit une bibliothèque nouvelle, std2::, par
exemple, ou std0x::, dans laquelle on met tout ce qui est
nouveau. Et éventuellement, on y copie tout ce qu'on veut garder
inchangé.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
| > hash_map n'est pas standard. Quand on a voulu ajouter ce genre de | > fonction en C++, il existait déjà plusieurs hash_map différents que | > divers compilateurs avaient induement placé dans std. Pour ne pas | > casser trop de code, il a donc été décidé que le standard se baserait | > sur un nom moins courant, donc cassant moins de code, bien que moins | > expressif.
| Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir | lu un article -- très probablement sur le site du WG21 -- dans lequel | était expliqué le pourquoi du nom «unordered_map» en lieu et pl ace de | «hash_map».
| Ton explication (qui coïncide je crois avec celle qu'avait founie ici | Gaby), est différente de ce que j'avais lu. Un des arguments en faveur | du nom «unordered_map», était que ce nom avait le mérite d'insi ster | sur le fait que les paires clés-valeurs n'était pas ordonnées.
Ça, c'est le genre de bullshit qu'on vend aux électeurs pendant les périodes de campagnes. C'est une raison trouvée après coût. J'imagine mal un document officiel du comité ISO C++ dire qu'ils ont pas pris le nom évident parce que MS s'est mal conduit.
Pas que Microsoft. Les premières versions de hash_map étaient prèsque toutes dans std::. Quand on s'en est rendu compte que ce n'était pas une bonne idée, g++ l'a déplacé dans un espace référentiel à part, mais il était à peu près le seul, je crois. (En tout cas, dans la version de la STLport livrée avec Sun CC, c'est aussi dans std.)
Le problème n'est pas simple. Une fois que tu l'as livré en std::, changer casse du code existant chez tes clients. Ce que ne veut faire aucun fournisseur responsable non plus. Alors, le bon choix dépend de beaucoup de paramètres. (Ou plutôt, il n'y a pas de bon choix : quoique tu fasses, ce n'est pas bon pour certains.)
Ensuite... Je crois qu'il y a quand même un concensus que le bon nom pour ces classes, c'est simplement set et map, et que les classes existantes doivent s'appeler ordered_set et ordered_map. Mais là aussi, c'est une option qui n'existe plus. (Au moins que... On garde le contenu de std tel qu'il est, sans le moindre changement, et on définit une bibliothèque nouvelle, std2::, par exemple, ou std0x::, dans laquelle on met tout ce qui est nouveau. Et éventuellement, on y copie tout ce qu'on veut garder inchangé.)
-- James Kanze (GABI Software) email: 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:
| Gabriel Dos Reis wrote: | > (Fabien Chêne) writes: | | > | Loïc Joly writes: | | > | > hash_map n'est pas standard. Quand on a voulu ajouter ce genre de | > | > fonction en C++, il existait déjà plusieurs hash_map différents que | > | > divers compilateurs avaient induement placé dans std. Pour ne pas | > | > casser trop de code, il a donc été décidé que le standard se baserait | > | > sur un nom moins courant, donc cassant moins de code, bien que moins | > | > expressif. | | > | Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir | > | lu un article -- très probablement sur le site du WG21 -- dans lequel | > | était expliqué le pourquoi du nom «unordered_map» en lieu et place de | > | «hash_map». | | > | Ton explication (qui coïncide je crois avec celle qu'avait founie ici | > | Gaby), est différente de ce que j'avais lu. Un des arguments en faveur | > | du nom «unordered_map», était que ce nom avait le mérite d'insister | > | sur le fait que les paires clés-valeurs n'était pas ordonnées. | | > Ça, c'est le genre de bullshit qu'on vend aux électeurs pendant les | > périodes de campagnes. C'est une raison trouvée après coût. | > J'imagine mal un document officiel du comité ISO C++ dire qu'ils ont | > pas pris le nom évident parce que MS s'est mal conduit. | | Pas que Microsoft. Les premières versions de hash_map étaient | prèsque toutes dans std::. Quand on s'en est rendu compte que ce | n'était pas une bonne idée, g++ l'a déplacé dans un espace | référentiel à part, mais il était à peu près le seul, je crois. | (En tout cas, dans la version de la STLport livrée avec Sun CC, | c'est aussi dans std.)
Tous les implémenteurs que je connais et qui participent aux travaux du comité l'ont deplacé, excepté un. Regarde aussi les archives du réflecteur lib.
-- Gaby
"kanze" <kanze@gabi-soft.fr> writes:
| Gabriel Dos Reis wrote:
| > fabien.chene@gmail.com (Fabien Chêne) writes:
|
| > | Loïc Joly <loic.actarus.joly@numericable.fr> writes:
|
| > | > hash_map n'est pas standard. Quand on a voulu ajouter ce genre de
| > | > fonction en C++, il existait déjà plusieurs hash_map différents que
| > | > divers compilateurs avaient induement placé dans std. Pour ne pas
| > | > casser trop de code, il a donc été décidé que le standard se baserait
| > | > sur un nom moins courant, donc cassant moins de code, bien que moins
| > | > expressif.
|
| > | Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir
| > | lu un article -- très probablement sur le site du WG21 -- dans lequel
| > | était expliqué le pourquoi du nom «unordered_map» en lieu et place de
| > | «hash_map».
|
| > | Ton explication (qui coïncide je crois avec celle qu'avait founie ici
| > | Gaby), est différente de ce que j'avais lu. Un des arguments en faveur
| > | du nom «unordered_map», était que ce nom avait le mérite d'insister
| > | sur le fait que les paires clés-valeurs n'était pas ordonnées.
|
| > Ça, c'est le genre de bullshit qu'on vend aux électeurs pendant les
| > périodes de campagnes. C'est une raison trouvée après coût.
| > J'imagine mal un document officiel du comité ISO C++ dire qu'ils ont
| > pas pris le nom évident parce que MS s'est mal conduit.
|
| Pas que Microsoft. Les premières versions de hash_map étaient
| prèsque toutes dans std::. Quand on s'en est rendu compte que ce
| n'était pas une bonne idée, g++ l'a déplacé dans un espace
| référentiel à part, mais il était à peu près le seul, je crois.
| (En tout cas, dans la version de la STLport livrée avec Sun CC,
| c'est aussi dans std.)
Tous les implémenteurs que je connais et qui participent aux travaux
du comité l'ont deplacé, excepté un. Regarde aussi les archives du
réflecteur lib.
| Gabriel Dos Reis wrote: | > (Fabien Chêne) writes: | | > | Loïc Joly writes: | | > | > hash_map n'est pas standard. Quand on a voulu ajouter ce genre de | > | > fonction en C++, il existait déjà plusieurs hash_map différents que | > | > divers compilateurs avaient induement placé dans std. Pour ne pas | > | > casser trop de code, il a donc été décidé que le standard se baserait | > | > sur un nom moins courant, donc cassant moins de code, bien que moins | > | > expressif. | | > | Je ne parviens pas à remettre la main dessus, mais je suis sur d'avoir | > | lu un article -- très probablement sur le site du WG21 -- dans lequel | > | était expliqué le pourquoi du nom «unordered_map» en lieu et place de | > | «hash_map». | | > | Ton explication (qui coïncide je crois avec celle qu'avait founie ici | > | Gaby), est différente de ce que j'avais lu. Un des arguments en faveur | > | du nom «unordered_map», était que ce nom avait le mérite d'insister | > | sur le fait que les paires clés-valeurs n'était pas ordonnées. | | > Ça, c'est le genre de bullshit qu'on vend aux électeurs pendant les | > périodes de campagnes. C'est une raison trouvée après coût. | > J'imagine mal un document officiel du comité ISO C++ dire qu'ils ont | > pas pris le nom évident parce que MS s'est mal conduit. | | Pas que Microsoft. Les premières versions de hash_map étaient | prèsque toutes dans std::. Quand on s'en est rendu compte que ce | n'était pas une bonne idée, g++ l'a déplacé dans un espace | référentiel à part, mais il était à peu près le seul, je crois. | (En tout cas, dans la version de la STLport livrée avec Sun CC, | c'est aussi dans std.)
Tous les implémenteurs que je connais et qui participent aux travaux du comité l'ont deplacé, excepté un. Regarde aussi les archives du réflecteur lib.
