Особенно ярко это различие проявляется при работе с контейнерами map
и multimap
, потому что эти контейнеры содержат объекты pair
, но их функции учитывают только значение ключа каждой пары. По этой причине функция count
считает только пары с совпадающими ключами (естественно, «совпадение» определяется по критерию эквивалентности); значение, ассоциированное с ключом, игнорируется. Функции find
, lower_bound
и т. д. поступают аналогично. Чтобы алгоритмы также ограничивались анализом ключа в каждой паре, вам придется выполнять акробатические трюки, описанные в совете 23 (что позволит заменить проверку равенства проверкой эквивалентности).
С другой стороны, если вы стремитесь к максимальной эффективности, то фокусы совета 23 в сочетании с логарифмической сложностью поиска алгоритмов из совета 34 могут показаться не такой уж высокой ценой за повышение быстродействия. А если вы
Таким образом, для стандартных ассоциативных контейнеров применение функций вместо одноименных алгоритмов обладает сразу несколькими преимуществами. Во-первых, вы получаете логарифмическую сложность вместо линейной. Во-вторых, «одинаковость» двух величин проверяется по критерию эквивалентности, более естественному для ассоциативных контейнеров. В-третьих, при работе с контейнерами map
и multimap
автоматически учитываются только значения ключей вместо полных пар (ключ, значение). Эти три фактора достаточно убедительно говорят в пользу функций классов.
Перейдем к функциям контейнера list
, имена которых совпадают с именами алгоритмов STL. В этом случае эффективность является практически единственным фактором. Алгоритмы, у которых в контейнере list
существуют специализированные версии (remove
, remove_if
, unique
, sort
, merge
и reverse
), копируют объекты, a list
-версии ничего не копируют; они просто манипулируют указателями, соединяющими узлы списка. По алгоритмической сложности функции классов и алгоритмы одинаковы, но если предположить, что операции с указателями обходятся значительно дешевле копирования объектов, list
-версии обладают лучшим быстродействием.
Следует помнить, что list
-версии часто ведут себя иначе, чем их аналоги-алгоритмы. Как объясняется в совете 32, для фактического удаления элементов из контейнера вызовы алгоритмов remove
, remove_if
и unique
должны сопровождаться вызовами erase
, однако одноименные функции контейнера list
честно уничтожают элементы, и последующие вызовы erase
не нужны.
Принципиальное различие между алгоритмом sort
и функцией sort
контейнера list
заключается в том, что алгоритм неприменим к контейнерам list
, поскольку ему не могут передаваться двусторонние итераторы list
. Алгоритм merge
также отличается от функции merge
контейнера list
— алгоритму не разрешено модифицировать исходные интервалы, тогда как функция list::merge
Теперь вы располагаете всей необходимой информацией. Столкнувшись с выбором между алгоритмом STL и одноименной функцией контейнера, предпочтение следует отдавать функции контейнера. Она почти всегда эффективнее работает и лучше интегрируется с обычным поведением контейнеров.
Совет 45. Различайте алгоритмы count, find, binary_search, lower_bound, upper_bound и equal_range
Предположим, вы ищете некоторый объект в контейнере или в интервале, границы которого обозначены итераторами. Как это сделать? В вашем распоряжении целый арсенал алгоритмов: count
, find
, binary_search
, lower_bound
, upper_bound
и equal_range
. Как же принять верное решение?
Очень просто. Основными критериями должны быть скорость и простота.
Временно предположим, что границы интервала поиска обозначены итераторами. Случай с поиском во всем контейнере будет рассмотрен ниже.