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

Q>Можешь задать этот вопрос непосредственно STL'ю (Stephan T. Lavavej).

Я этот вопрос ему непосредственно задал. Ответом было "намного важнее не допустить вырожденного (O[n]) поведения чем преследовать более частое оптимальное поведение." Т.е. при плохом наборе входных значений текущая хэш-функция всё равно прекрасно перемешает биты и распихает числа по разным бакетам, в то время как identity с радостью всё сложит в один. Я немного поспорил, потому что не согласен с настолько жестоким ударом по ничего не подозревающим программистам, но Степан уверен что так лучше, потому баг в конце концов был закрыт как "by design"

Вроде как есть для этого оправдание: в MSVC используют power-of-2 для числа бакетов, а в остальных стлях — prime number. Получается что при вычислении индекса MSVC делает битовое и, и оставшиеся биты у хэща используются те что были. В гцц/кланге берётся остаток от деления на простое число, который сам по себе достаточно сильно меняет число, но заметно тяжелее как операция. Так identity hash работает отлично для гцц/кланга, но опасен в MSVC.

Выбор степеней двойки как числа бакетов позволяет сконфигурировать контейнер эффективнее если знать входные данные и самому написать хэшфункцию под них, но очень мешает сделать быстро в общем виде. Простые числа работают ровно наоборот.