вопрос по unordered_map

и размер значения может быть большим

Значение выпихнуть в (умный) указатель и оно опять маленькое.

ну это я образно написал большой, рассчитываю на сотню байт :)

Хранить надо только в оперативной памяти?

https://stackoverflow.com/questions/2196995/is-there-any-advantage-of-using-m...

Just from personal experience, I found an enormous improvement in performance (measured, of course) when using an unordered_map isntead of a map in a main entity look-up table.

ага, а хеш как считать? По укзателю?

да, только в ОП

Да вот подсчёт хеша по указателю может создать проблему? Ну тоесть если адрес переменной 0х000000, а я например в виде ключа хочу использовать такие числа, разве нельзя? А если я ключом сделаю файловые дескрипторы? Так там вообще просто числа 1 2 3... указатели кстати у меня не перекрываемые.

а хеш как считать? По укзателю?

Зачем значению хеш? Ключ — UUID — он маленький

Да вот подсчёт хеша по указателю может создать проблему?

Та не, считай себе, только вот хеш функция будет обрабатывать все большое тело обьекта.

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

Тут надо смотреть, какое именно поведение тебе нужно.

ЗЫ: провтыкал, думал, было предложено ключ ч-з указатель пробрасывать )

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

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

Вопрос в том, будешь ли ты такие обьекты считать одинаковыми или нет?

это не важно, каждый объект в мапе не зависит от других и они могут быть хоть все одинаковыми, а по требованию unordered_map главное только уникальный ключ. У меня могут два пользователя с уникальными uuid сохранить грубо говоря число 2 в мапе и это не должно никаких проблем вызывать. Единственное условие не должно быть перекрывающихся указателей. Вот в таком случае я считаю объекты одинаковыми и запрещаю такое поведение. Я надеюсь смог ответить на твой вопрос, а то чувствую что туплю :)

когда я писал «обьект», то имел ввиду ключ )

ну ключ же uuid? как он может быть одинаковый у разных юзеров? И каждый юзер пишет в свою ячейку так скажем. ААААААААА я туплю %)

является ли unordered_map самым быстрым среди ассоциативных массивов по доступу по ключу

нетЪ. хотите максимальной оптимизации — не юзайте STL. http://comdivbyzero.blogspot.ru/2013/07/blog-post_20.html

И что вообще посоветуете для хранения таких пар «UUID»->«lol» которых не больше 100к и размер значения может быть большим.

зависит от ситуации. в стдлибе вон сделали кривое для общего алгоритма решение в виде поиска по указателю, а не по-настоящему UUID.

но для каких-то случаев такое решение будет идеальным

ну у меня такая ситуация: сервер для каждого клиента хранит его данные, ну чтоб каждый раз их не пересылать, вот я и подумал что в таком случае пара uuid->«структура этих данных» будет норм, а про 100к я написал чтоб быть уверенным что такой массив не станет узким местом при возможном увеличении клиентов :)

числа клиентов*

unordered_map тогда

ок, спс.