Подавление подстановки кода функций объясняет один факт, который кажется невероятным многим опытным программистам C: функция C++

почти всегда превосходит по скорости функцию C . Конечно, в C++ приходится создавать экземпляры шаблонов функций и вызывать , тогда как в C все ограничивается простым вызовом функции, однако все «излишества» C++ теряются во время компиляции. На стадии выполнения обращается к подставленной функции сравнения (при условии, что функция была объявлена с ключевым словом , а ее тело доступно на стадии компиляции), тогда как вызывает функцию сравнения через указатель. Результат — работает гораздо быстрее. В моих тестах с вектором, содержащим миллион чисел , превосходство по скорости достигало 670%, но я не призываю верить мне на слово. Вы легко убедитесь в том, что при передаче объектов функций в качестве параметров алгоритмов «плата за абстракцию» превращается в «премию за абстракцию».

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

длину всех строк в множестве:

Проблема возникает из-за ошибки в работе с константными функциями классов (такими как

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

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

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

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

Многие компиляторы принимают этот код, но по Стандарту C++ он считается недопустимым. Дело в том, что теоретически может существовать другой шаблон функции с именем

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