На собеседованиях меня периодически спрашивают, что делать если количество данных вставляемых в
unordered_map неизвестно заранее. Т.е. подобрать контейнер необходимого размера заранее нельзя и rehash
будет вызываться неопределенное число раз, что отрицательно сказывается на производительности.
Очевидно ожидается какой-то стандартный ответ, какой именно?

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

S>На собеседованиях меня периодически спрашивают, что делать если количество данных вставляемых в
S>unordered_map неизвестно заранее. Т.е. подобрать контейнер необходимого размера заранее нельзя и rehash
S>будет вызываться неопределенное число раз, что отрицательно сказывается на производительности.
S>Очевидно ожидается какой-то стандартный ответ, какой именно?

что-то не припомню такого стандартного вопроса
могу предположить, что надо позвать какой-нибудь метод типа reserve : http://en.cppreference.com/w/cpp/container/unordered_map/reserve
посмотрите методы из группы Hash policy отсюда: http://en.cppreference.com/w/cpp/container/unordered_map

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

U>что-то не припомню такого стандартного вопроса
U>могу предположить, что надо позвать какой-нибудь метод типа reserve : http://en.cppreference.com/w/cpp/container/unordered_map/reserve
U>посмотрите методы из группы Hash policy отсюда: http://en.cppreference.com/w/cpp/container/unordered_map

Нет, reserve в данном контексте неверный ответ.

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

возможно хотели услышать о std::unordered_map::load_factor

но очевидно, что подобные вопросы задают вчерашние школьники, так что не расстраивайтесь.

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

S>будет вызываться неопределенное число раз, что отрицательно сказывается на производительности.

Да и ладно с ним.
Главное, что в нём есть такой автоматический рехеш.
(В отличии от, например, CMap из MFC)

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

S>На собеседованиях меня периодически спрашивают, что делать если количество данных вставляемых в
S>unordered_map неизвестно заранее. Т.е. подобрать контейнер необходимого размера заранее нельзя и rehash
S>будет вызываться неопределенное число раз, что отрицательно сказывается на производительности.
S>Очевидно ожидается какой-то стандартный ответ, какой именно?

А и пофиг, вот наш стандартный ответ.
Если стратегия рехеша — удваивать число корзин при достижении max_load_factor, то это даст усреднённый вклад O(1) на вставку одного элемента.
Так же, как с push_back в вектор.