Discussion :

[oodini]

C'est effectivement plus propre, mais ça sera à faire quand j'aurai le temps. :-)

[koala01]

Je n'ai pas besoin d'un ordre de tri particulier, et je ne vois pas en quoi j'économiserais de la mémoire, car la clé serait dans le vecteur plutôt que dans le map.

Justement, non!!

Avec un vecteur, tu utilise l'algorithme sort, en fournissant le foncteur qui t'intéresse por le tri, et basta: ton vecteur ne contient que les données (qui seront triées en conséquence de tes souhaits).

Par contre, une map manipule une paire clé / valeur, ce qui revient à utiliser deux représentations distinctes mais équivalentes de la même chose, avec toujours le risque de collision lorsque tu recrées la clé!

Le seul argument serait celui relatif à la manipulation des paires (honni soit qui mâle y pense). Mais je ne le trouve pas si critique.

Il y a surtout le fait que, si tu veux modifier le critère de tri avec une map, tu n'auras pas le choix : il te faudra repartir d'une map vide que tu remplira, de sorte à ce que ta map soit correctement triée.

Même si ce n'est que pour un petit instant, tu te trouveras donc avec deux map contenant les mêmes informations, qui sont "simplement" triées de manière différentes (et donc avec deux fois plus de données que nécessaires).

Comme tu "dupliques" déjà les données pour créer ta clé, tu te retrouve grosso modo, même si c'est pendant un bref instant, avec une consomation mémoire qui "explose" littéralement à près de quatre fois ce qui est nécessaire

Et comme la map utilise un arbre binaire en interne, je te laisse imaginer le nombre d'allocations / libérations de mémoire que cela peut représenter

Quand tu penses que, au pire, l'algorithme sort va copier les objets deux à deux, que tu peux garder strictement le même vecteur et que, une fois qu'il est rempli, la modificication du critère de tri ne demandera plus la moindre allocation dynamique supplémentaire...

Je me dis que, à moins que tu n'aies vraiment besoin d'accéder par clé à tes objets, la manipulation d'un vecteur sera largement plus intéressante, à tous points de vues

Je trouve que l'utilisation des map est en outre plus conforme à une conception intuitive de ce qu'il faut coder.

C'est surement bien mieux que d'utiliser un vecteur de vecteur de vecteur comme tu en avait l'intuition au début

Et cela correspond sans doute beaucoup plus à tes besoins, mais, si tu encapsule le tout dans un objet qui aurait pour responsabilité de gérer tes enregistrements (en cachant le type de collection manipulé), tu auras sans doute de bien meilleures performances en utilisant un vecteur de structures

[oodini]

Avec un vecteur, tu utilise l'algorithme sort, en fournissant le foncteur qui t'intéresse por le tri, et basta: ton vecteur ne contient que les données (qui seront triées en conséquence de tes souhaits).

Par contre, une map manipule une paire clé / valeur, ce qui revient à utiliser deux représentations distinctes mais équivalentes de la même chose, avec toujours le risque de collision lorsque tu recrées la clé!

C'est là que vous vous fourvoyez. Il n'y a pas redondance d'informations entre la clé et la valeur.

En gros, la clé est la représentation de l'intersection d'ensembles, du genre : "donne moi la liste de toutes les voitures vertes décapotables avec un chien qui dit oui sur la plage arrière".
La couleur de la voiture sera codée sur un chiffre, le type (décapotable, berline...) sur un aute, etc. Et dans la valeur, tu auras une liste d'instances de structures correspondant à chaque voiture correspondant aux critères donnés.

Je pourrais certes ramener les données utilisées comme critères de recherches dans la structure, et faire un vecteur, mais d'une part, je devrais me taper le codage du tri, et d'autre part, il ne serait plus aussi évident de voir quelles seraient les caractéristiques utilisées comme critères de recherche, par rapport aux caractéristiques lambda.