Древовидные контейнеры Boost:: Вариант - есть ли недостатки?

Question

Видимо можно заказать карты и наборы boost::variant, как это:

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";

выход:

1 7
a 3

Однако я нахожу это несколько подозрительным; Я посмотрел в исходный код, чтобы увидеть, как это может работать, но не получил много от него... как-то нужно сравнивать различные типы operator<... которые должны быть определены для любых 2 типов; кроме того, сравнивая различные типы с < само по себе не имеет смысла для меня. Поэтому мне интересно, есть ли подвох в использовании карт или наборов boost::variant с точки зрения производительности. Есть ли подвох? Или это нормально иметь карты или наборы boost::variant?

Answer 1

В конце концов я нашел это в документации: http://www.boost.org/doc/libs/1_63_0/doc/html/variant/reference.html

Каждый тип, указанный в качестве аргумента шаблона для варианта, должен как минимум соответствовать вышеуказанным требованиям. Кроме того, определенные функции варианта доступны только в том случае, если его ограниченные типы соответствуют требованиям следующих дополнительных понятий:

...

LessThanComparable: вариант сам по себе LessThanComparable тогда и только тогда, когда каждый из его ограниченных типов соответствует требованиям концепции.

поскольку string, int а также bool являются все LessThanComparable тогда в этом случае код является безопасным и правильным.