J'avoue personnellement que pour un langage dont beaucoup de locuteur mettent la performance en première qualité et souhaitant éviter tout tests inutiles avoir comme unique implémentation une map "over featured" et surprenant.
Il existait d'autres moyens d'arriver à ses fins avant cette map standard, et ce n'est pas vraiment en contradiction avec les qualités mises en avant par ses locuteurs : cette implémentation standard se veut performante et sans tests inutiles pour un cas qui a été jugé courant (ordonné) et difficile...
Les versions normalisées mettent du temps et plusieurs acteurs (libres et propriétaires) sont impliqués. Du coup ça correspond bien aux besoins consensuels au moment de sa sortie. Fort de cela, pour ma part, je trouve dommage qu'il n'y ait pas eu std::ordrered_map et std::unordrered_map dès le début, avec std::map comme alias/synonyme du premier (puisque c'était le besoin/cas principal/courant.)
on risque l'ossification du langage voir du langage à plusieurs niveau avec toute une pile non standard qui tente de créer une norme au dessus de la norme.
Ce n'est pas un risque mais bien l'approche choisie (àmha) contrairement à d'autres (Go, Java, Rust, etc.) Mais il n'y a pas vraiment d'approche qui soit vraiment meilleure qu'une autre (àmha) car chacun a sa philosophie, sa cible, et divers paramètres.
Ceci dit, j'ai l'impression qu'il y a une certaine précipitation (ce que tu appelles "aller dans tous les sens" je pense) pour coller à une supposée concurrence (pourtant, les langages ne devraient s'opposer) & ne plus faire son âge vénérable...
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: Héritage de std::map
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Effortless Performance Improvements in C++: std::unordered_map. Évalué à 2.
Il existait d'autres moyens d'arriver à ses fins avant cette map standard, et ce n'est pas vraiment en contradiction avec les qualités mises en avant par ses locuteurs : cette implémentation standard se veut performante et sans tests inutiles pour un cas qui a été jugé courant (ordonné) et difficile...
Les versions normalisées mettent du temps et plusieurs acteurs (libres et propriétaires) sont impliqués. Du coup ça correspond bien aux besoins consensuels au moment de sa sortie. Fort de cela, pour ma part, je trouve dommage qu'il n'y ait pas eu
std::ordrered_mapetstd::unordrered_mapdès le début, avecstd::mapcomme alias/synonyme du premier (puisque c'était le besoin/cas principal/courant.)Ce n'est pas un risque mais bien l'approche choisie (àmha) contrairement à d'autres (Go, Java, Rust, etc.) Mais il n'y a pas vraiment d'approche qui soit vraiment meilleure qu'une autre (àmha) car chacun a sa philosophie, sa cible, et divers paramètres.
Ceci dit, j'ai l'impression qu'il y a une certaine précipitation (ce que tu appelles "aller dans tous les sens" je pense) pour coller à une supposée concurrence (pourtant, les langages ne devraient s'opposer) & ne plus faire son âge vénérable...
"It is seldom that liberty of any kind is lost all at once." ― David Hume