conteneurs arborescents de boost :: variant - y a-t-il des inconvénients?

Question

Apparemment, il est possible d'avoir commandés cartes et jeux de boost::variant, comme ceci:

typedef boost::variant<std::string, int, bool> key_type; 
std::map<key_type, size_t> m; 

m.insert(std::make_pair(std::string("a"), 3)); 
m.insert(std::make_pair(1, 7)); 
auto x = m.find(1); 
std::cout << x->first << " " << x->second << "\n"; 
x = m.find(std::string("a")); 
std::cout << x->first << " " << x->second << "\n"; 

sortie:

1 7 
a 3 

Cependant, je trouve cela un peu suspect; J'ai regardé dans le code source pour voir comment cela peut fonctionner, mais je n'en ai pas tiré grand chose ... d'une certaine manière les différents types doivent être comparés avec operator< ... qui devrait être défini pour 2 types; Mis à part cela, comparer différents types avec < n'a aucun sens en soi pour moi. Par conséquent, je me demande s'il y a un piège à utiliser des cartes ou des ensembles de boost::variant en termes de performance. Y a-t-il une prise? Ou est-ce correct d'avoir des cartes ou des ensembles de boost::variant?

Answer 1

je finalement l'ai trouvé dans la documentation: http://www.boost.org/doc/libs/1_63_0/doc/html/variant/reference.html

Chaque type spécifié comme argument de modèle à la variante doit au minimum satisfaire aux exigences ci-dessus. De plus, certaines caractéristiques de la variante sont disponibles que si ses types bornés répondent aux exigences de ces concepts suivants:

...

LessThanComparable: variante est elle-même LessThanComparable si et seulement si chacun de ses types bornés répond aux exigences du concept.

depuis string, int et bool sont tous LessThanComparable alors dans ce cas, le code est correct et sûr.