Здравствуйте, saf_e, Вы писали:

_>Здравствуйте, watchmaker, Вы писали:

W>>Но тут, конечно же всё ломается из-за неперемещаемых типов:

struct U {
W>>    U(int);
W>>    U(const U&) = delete; // oops
W>>    friend bool operator==(const U&, const U&);
W>>};
W>>

W>>а сейчас такой emplace валидный.

_>Сразу напрашивается создавать сначала только ключ, а потом ноду )

И это даже не скомпилируется с тем классом, который ты так предусмотрительно процитировал в сообщении.


_> т.к. обычно обьект ключа легковесный, а вся жесть в значении )

Да, но отчасти это ещё и из-за того, что стандартная библиотека С++ довольно бедна контейнерами и структурами данных. А существующие вынуждают делать ключи именно такими.
Если бы в стандарте было что-то похожее на boost.bimap или boost.multi_index, то такое разделение на лёгкие ключи и тяжелые значения встречалось бы чуть реже.


W>>А если и это множество типов игнорировать, то сломается на типах, значение hash у которых зависит от this (как в python) (может кто-то безумный элементы DSU хранит в hash-map). И опять без знаний об внутреннем устройстве конструктора эту проблему не обойти.

_>мне кажется это не валидно в принципе, т.к. как вы его искать планируете?

Отлично ищется: https://godbolt.org/z/cTP6ccqT1
В чём проблема?
Тут, конечно, игрушечный пример, но например, во всяких графах такое встречается, когда вершины уникальные (и поэтому для нет необходимости вводить идентификаторы, а достаточно уже гарантированно уникального this), а ребра определяются связями между вершинами.

Также метод find и прочие не про просто так сделаны гетерогенными: можно делать поиск не конструируя ключ. Например, если у тебя есть множество умных указателей, то в нём можно найти элемент по указываемому адресу (т.е. по сырому указателю), не конструируя из него другой умный указатель.