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

_DA>Здравствуйте, IROV.., Вы писали:

IRO>>Одна итерация, так одна от begin -> end ^^
_DA>Просто в N раз никакого замедления не будет, максимум в 2 из-за ненужного вызова equal_range.
2 это тоже N ^^ + хвостик от Distance

_DA>А кому нужна эта конкретная обобщенность кроме самих разработчиков stl? Мне от stl часто нужна скорость.
"Вы просто не умеите их готовить" (с)

count не совсем отображает мысль "есть ли такой обьект", то что мелкие не сделали специализацию под случай Unique Associative Container, ну что я прощаю ^^, я не буду использовать изврат, и надеятся на обьективность.

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

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

B>>Может быть будут аргументы?
IRO>Гавно, вопрос.
Да уж, прекрасный стиль

IRO>

IRO>    size_type count(const key_type& _Keyval) const
IRO>        {    // count all elements that match _Keyval
IRO>        _Paircc _Ans = equal_range(_Keyval);
IRO>        size_type _Num = 0;
IRO>        _Distance(_Ans.first, _Ans.second, _Num);
IRO>        return (_Num);
IRO>        }
IRO>

IRO>что мы тут видем, equal_range -> два find.
В случае multimap — да, в случае map — в нормальных реализациях find только один.

IRO>Distance!! может для когото секрет, что итерация у std::map это совсем не константная операция.
Да, итерация по дереву не самая дешевая операция, но опять же не для данного случая (т.е. для случая map).

Подводя итог.
Я, в принципе, согласен с аргументами против count, и сам использую find. Но варианты с count приходилось встречать, да и в драфте C++0x этот метод не объявлен как deprecated — так что этот вариант вполне имеет право на жизнь.