Для контейнеров

и в качестве возможных кандидатов для поиска первого объекта с заданным значением указаны два алгоритма, и . Обычно для решения этой задачи выбирается — возможно, вы обратили внимание, что именно этот алгоритм указан в таблице для контейнеров и . Однако – контейнеры не гарантируют, что при наличии нескольких элементов с заданным значением найдет первый элемент в контейнере; известно лишь то, что будет найден один из этих элементов. Если вы действительно хотите найти первый объект с заданным значением, воспользуйтесь и выполните вручную вторую часть проверки эквивалентности, описанной в совете 19 (без этой проверки можно обойтись при помощи , но вызов обходится дороже, чем вызов ).

Выбрать между

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

Часто говорят, что повышение уровня абстракции языков высокого уровня приводит к снижению эффективности сгенерированного кода. Александр Степанов, изобретатель STL, однажды разработал небольшой комплекс тестов для оценки «платы за абстракцию» при переходе с C на C++. В частности, результаты этих тестов показали, что код, сгенерированный для работы с классом, содержащим

, почти всегда уступает по эффективности соответствующему коду, непосредственно работающему с . С учетом сказанного вас может удивить тот факт, что передача алгоритмам объектов функций STL — то есть объектов, маскирующихся под функции, — обычно обеспечивает более эффективный код, чем передача «настоящих» функций.

Предположим, вы хотите отсортировать вектор чисел типа

по убыванию. Простейшее решение этой задачи средствами STL основано на использовании алгоритма с объектом функции типа :

Вспомнив о «плате за абстракцию», программист решает заменить объект функции «настоящей» функцией, которая к тому же оформлена как подставляемая (

):

Как ни странно, хронометраж двух вызовов sort показывает, что вызов с

почти всегда работает быстрее. В своих тестах я сортировал вектор, содержащий миллион чисел типа , на четырех разных платформах STL с оптимизацией по скорости, и версия с всегда работала быстрее. В худшем случае выигрыш в скорости составил 50%, в лучшем он достигал 160%. Вот тебе и «плата за абстракцию»…

Факт объясняется просто. Если функция

объекта функции была объявлена подставляемой (явно, с ключевым словом , или косвенно, посредством определения внутри определения класса), большинство компиляторов благополучно подставляет эту функцию во время создания экземпляра шаблона при вызове алгоритма. В приведенном выше примере это происходит с функцией . В результате код не содержит ни одного вызова функций, а для такого кода компилятор может выполнить оптимизацию, недоступную при наличии вызовов (связь между подстановкой функций и оптимизацией компиляторов рассматривается в совете 33 «Effective C++» и главах 8-10 книги «Efficient C++» [10]).

При вызове

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

алгоритму

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

Поскольку

является указателем на функцию, при каждом его использовании внутри sort происходит косвенный вызов функции (то есть вызов через указатель). Большинство компиляторов не пытается подставлять вызовы функций, вызываемых через указатели, даже если функция объявлена с ключевым словом и оптимизация выглядит очевидной. Почему? Наверное, потому, что разработчики компиляторов не считают нужным ее реализовать. Пожалейте их — народ постоянно чего-нибудь требует, а успеть все невозможно. Впрочем, это вовсе не означает, что требовать не нужно.