Чтение онлайн

Подробности нас сейчас не интересуют. Обратите внимание: предикат 

сначала передается , а затем . Конечно, в обоих случаях  передается по значению — то есть копируется (теоретически возможны исключения, но на практике дело обстоит именно так; за подробностями обращайтесь к совету 38).

Первый вызов

(расположенный в клиентском коде, удаляющем третий элемент из ) создает анонимный объект с внутренней переменной , равной 0. Этот объект, известный в под именем , затем копируется в , поэтому тоже получает объект с переменной , равной 0. Алгоритм «вызывает» этот объект, пока тот не вернет ; таким образом, объект вызывается три раза. Затем возвращает управление . продолжает выполняться и в итоге вызывает , передавая в качестве предиката очередную копию . Но переменная объекта  по-прежнему равна 0! Ведь алгоритм вызывал не , а лишь копию . В результате при третьем вызове из предикат тоже вернет . Теперь понятно, почему удаляет два объекта вместо одного.

Чтобы обойти эту лингвистическую ловушку, проще всего объявить функцию

с ключевым словом в предикатном классе. В этом случае компилятор не позволит изменить переменные класса:

Из-за простоты этого решения я чуть было не озаглавил этот совет «Объявляйте

константным в предикатных классах», но этой формулировки недостаточно. Даже константные функции могут обращаться к – переменным, неконстантным локальным статическим объектам, неконстантным статическим объектам класса, неконстантным объектам в области видимости пространства имен и неконстантным глобальным объектам. Хорошо спроектированный предикатный класс должен обеспечить независимость функций и от этих объектов. Объявление константных функций в предикатных классах необходимо для правильного поведения, но не достаточно. Правильно написанная функция является константной, но это еще не все. Она должна быть «чистой» функцией.

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

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

Как бы вы ни программировали предикаты, они всегда должны быть «чистыми» функциями.

Предположим, у нас имеется список указателей

и функция, которая по указателю определяет, является ли объект «интересным»:

Если потребуется найти в списке первый указатель на «интересный» объект

, это делается легко:

С другой стороны, если потребуется найти первый указатель на «неинтересный» объект

, следующее очевидное решение не компилируется:

Перед

к функции необходимо применить :

При виде этого решения невольно возникают вопросы. Почему мы должны применять

к isInteresting перед ? Что для нас делает и почему начинает работать приведенная выше конструкция?

Ответ оказывается весьма неожиданным. Вся работа

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