забудь про хеш; нет ничего (по крайней мере, из вашего вопроса), которое предполагает, что у вас есть значимый ключ;
Давайте сделаем шаг назад и перефразируем ваши фактические цели производительности:
- вы хотите быстро проверить, не существует ли дубликатов ни для одного из ваших объектов State
комментарий, если мне нужно добавить другие.
Исходя из вышеупомянутой цели и вашего комментария, я бы предложил вам использовать orders_set вместо unordered_map. Да, упорядоченный поиск использует бинарный поиск O (log (n)), в то время как неупорядоченный использует поиск O (1).
Однако, разница в том, что при таком подходе вам нужно order_set ONLY , чтобы проверить, что подобное состояние уже не существует , когда вы собираетесь создать новое , то есть в состоянии время создания .
В всех других поисках вам на самом деле не нужно заглядывать в order_set! потому что у вас уже есть ключ; Состояние *, и ключ может получить доступ к значению с помощью оператора магического разыменования: * ключ
так что при таком подходе вы используете order_set только как index для проверки состояний только на время создания. Во всех остальных случаях вы получаете доступ к вашему состоянию с помощью оператора разыменования вашего ключа-указателя.
если всего вышеперечисленного недостаточно, чтобы убедить вас, вот последний гвоздь в гробу идеи использования хеша для быстрого определения равенства; хэш-функция имеет небольшую вероятность столкновения, но с ростом числа состояний эта вероятность станет полной достоверностью. Таким образом, в зависимости от вашей отказоустойчивости, вы будете иметь дело с коллизиями состояний (и исходя из вашего вопроса и количества штатов, которые вы ожидаете иметь дело, кажется, вы будете иметь дело со многими из них)
Чтобы это работало, вам, очевидно, нужен предикат сравнения для проверки всех внутренних свойств вашего состояния (гироскоп, двигатели, акселерометры, протонные лучи и т. Д.)