Сообщение Re[6]: unorderd_map внутри unordered_map и emplace() от 12.01.2022 2:08
Изменено 13.01.2022 17:24 watchmaker
Re[6]: unorderd_map внутри unordered_map и emplace()
Здравствуйте, saf_e, Вы писали:
_>Здравствуйте, watchmaker, Вы писали:
W>>Но тут, конечно же всё ломается из-за неперемещаемых типов:
W>>а сейчас такой emplace валидный.
_>Сразу напрашивается создавать сначала только ключ, а потом ноду )
И это даже не скомпилируется с тем классом, который ты так предусмотрительно процитировал в сообщении.
_> т.к. обычно обьект ключа легковесный, а вся жесть в значении )
Да, но отчасти это ещё и из-за того, что стандартная библиотека С++ довольно бедна контейнерами и структурами данных. А существующие вынуждают делать ключи именно такими.
Если бы в стандарте было что-то похожее на boost.bimap или boost.multi_index, то такое разделение на лёгкие ключи и тяжелые значения встречалось бы чуть реже.
W>>А если и это множество типов игнорировать, то сломается на типах, значение hash у которых зависит от this (как в python) (может кто-то безумный элементы DSU хранит в hash-map). И опять без знаний об внутреннем устройстве конструктора эту проблему не обойти.
_>мне кажется это не валидно в принципе, т.к. как вы его искать планируете?
Отлично ищется: https://godbolt.org/z/dhhafr8b1
В чём проблема?
Тут, конечно, игрушечный пример, но например, во всяких графах такое встречается, когда вершины уникальные (и поэтому для нет необходимости вводить идентификаторы, а достаточно уже гарантированно уникального this), а ребра определяются связями между вершинами.
Также метод find и прочие не про просто так сделаны гетерогенными: можно делать поиск не конструируя ключ. Например, если у тебя есть множество умных указателей, то в нём можно найти элемент по указываемому адресу (т.е. по сырому указателю), не конструируя из него другой умный указатель.
_>Здравствуйте, 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/dhhafr8b1
В чём проблема?
Тут, конечно, игрушечный пример, но например, во всяких графах такое встречается, когда вершины уникальные (и поэтому для нет необходимости вводить идентификаторы, а достаточно уже гарантированно уникального this), а ребра определяются связями между вершинами.
Также метод find и прочие не про просто так сделаны гетерогенными: можно делать поиск не конструируя ключ. Например, если у тебя есть множество умных указателей, то в нём можно найти элемент по указываемому адресу (т.е. по сырому указателю), не конструируя из него другой умный указатель.
Re[6]: unorderd_map внутри unordered_map и emplace()
Здравствуйте, saf_e, Вы писали:
_>Здравствуйте, watchmaker, Вы писали:
W>>Но тут, конечно же всё ломается из-за неперемещаемых типов:
W>>а сейчас такой emplace валидный.
_>Сразу напрашивается создавать сначала только ключ, а потом ноду )
И это даже не скомпилируется с тем классом, который ты так предусмотрительно процитировал в сообщении.
_> т.к. обычно обьект ключа легковесный, а вся жесть в значении )
Да, но отчасти это ещё и из-за того, что стандартная библиотека С++ довольно бедна контейнерами и структурами данных. А существующие вынуждают делать ключи именно такими.
Если бы в стандарте было что-то похожее на boost.bimap или boost.multi_index, то такое разделение на лёгкие ключи и тяжелые значения встречалось бы чуть реже.
W>>А если и это множество типов игнорировать, то сломается на типах, значение hash у которых зависит от this (как в python) (может кто-то безумный элементы DSU хранит в hash-map). И опять без знаний об внутреннем устройстве конструктора эту проблему не обойти.
_>мне кажется это не валидно в принципе, т.к. как вы его искать планируете?
Отлично ищется: https://godbolt.org/z/cTP6ccqT1
В чём проблема?
Тут, конечно, игрушечный пример, но например, во всяких графах такое встречается, когда вершины уникальные (и поэтому для нет необходимости вводить идентификаторы, а достаточно уже гарантированно уникального this), а ребра определяются связями между вершинами.
Также метод find и прочие не про просто так сделаны гетерогенными: можно делать поиск не конструируя ключ. Например, если у тебя есть множество умных указателей, то в нём можно найти элемент по указываемому адресу (т.е. по сырому указателю), не конструируя из него другой умный указатель.
_>Здравствуйте, 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 и прочие не про просто так сделаны гетерогенными: можно делать поиск не конструируя ключ. Например, если у тебя есть множество умных указателей, то в нём можно найти элемент по указываемому адресу (т.е. по сырому указателю), не конструируя из него другой умный указатель.