Quel problème cela résout-il,
Voir la réponse de Dietmar et la réponse de remyabel .
et cela change-t-il le fonctionnement des conteneurs standard?
Non, pas par défaut.
Les nouvelles surcharges de modèle de fonction membre de find
etc. vous permettent d'utiliser un type comparable à la clé du conteneur, au lieu d'utiliser le type de clé lui-même. Voir N3465 par Joaquín Mª López Muñoz pour la justification et une proposition détaillée et soigneusement écrite pour ajouter cette fonctionnalité.
Lors de la réunion de Bristol, le LWG a convenu que la fonction de recherche hétérogène était utile et souhaitable, mais nous ne pouvions pas être sûrs que la proposition de Joaquín serait sûre dans tous les cas. La proposition N3465 aurait causé de sérieux problèmes pour certains programmes (voir la section Impact sur le code existant ). Joaquín a préparé un projet de proposition mis à jour avec des implémentations alternatives avec différents compromis, ce qui était très utile pour aider le LWG à comprendre les avantages et les inconvénients, mais ils risquaient tous de casser certains programmes d'une manière ou d'une autre, il n'y avait donc pas de consensus pour ajouter la fonctionnalité. Nous avons décidé que même s'il ne serait pas sûr d'ajouter la fonctionnalité sans condition, ce serait sûr si elle était désactivée par défaut et uniquement "opt-in".
La principale différence de la proposition N3657 (qui était une révision de dernière minute par moi-même et STL basée sur N3465 et un projet ultérieur non publié par Joaquín) était d'ajouter le is_transparent
type comme protocole qui peut être utilisé pour opter pour la nouvelle fonctionnalité.
Si vous n'utilisez pas de "foncteur transparent" (c'est-à-dire celui qui définit un is_transparent
type) alors les conteneurs se comportent comme ils l'ont toujours fait, et c'est toujours la valeur par défaut.
Si vous choisissez d'utiliser std::less<>
(ce qui est nouveau pour C ++ 14) ou un autre type de "foncteur transparent", vous obtenez la nouvelle fonctionnalité.
L'utilisation std::less<>
est facile avec les modèles d'alias:
template<typename T, typename Cmp = std::less<>, typename Alloc = std::allocator<T>>
using set = std::set<T, Cmp, Alloc>;
Le nom is_transparent
vient du N3421 de STL qui a ajouté les "opérateurs diamantés" au C ++ 14. Un "foncteur transparent" est celui qui accepte tous les types d'arguments (qui ne doivent pas nécessairement être identiques) et transmet simplement ces arguments à un autre opérateur. Un tel foncteur se trouve être exactement ce que vous voulez pour une recherche hétérogène dans des conteneurs associatifs, de sorte que le type a is_transparent
été ajouté à tous les opérateurs de diamant et utilisé comme type de balise pour indiquer que la nouvelle fonctionnalité doit être activée dans les conteneurs associatifs. Techniquement, les conteneurs n'ont pas besoin d'un "foncteur transparent", juste un qui prend en charge l'appeler avec des types hétérogènes (par exemple, le pointer_comp
type dans https://stackoverflow.com/a/18940595/981959 n'est pas transparent selon la définition de STL,pointer_comp::is_transparent
permet de l'utiliser pour résoudre le problème). Si vous ne jamais votre recherche dans std::set<T, C>
des clés de type T
ou int
alors C
besoin que d'être appelable avec des arguments de type T
et int
(dans un ordre), il n'a pas besoin d'être vraiment transparent. Nous avons utilisé ce nom en partie parce que nous ne pouvions pas trouver un meilleur nom (j'aurais préféré is_polymorphic
parce que ces foncteurs utilisent le polymorphisme statique, mais il existe déjà un std::is_polymorphic
trait de type qui fait référence au polymorphisme dynamique).