Другая причина, по которой объекты функций предпочтительнее обычных функций, заключается в том, что они помогают обойти хитрые синтаксические ловушки. Иногда исходный текст, выглядящий вполне разумно, отвергается компилятором по законным, хотя и неочевидным причинам. Например, в некоторых ситуациях имя экземпляра, созданного на базе шаблона функции, не эквивалентно имени функции. Пример:
template<typename FPType> // Вычисление среднего
FPType average(FPType val1, FPType val2) // арифметического двух
{ //вещественных чисел
return (val1 + val2)/2;
};
template<typename InputIter1, typename InputIter2>
void writeAverages(InputIter begin1, // Вычислить попарные
InputIter end1, // средние значения
InputIter begin2, // двух серий элементов
ostream& s) { // в потоке
transform(begin1, end1, begin2,
ostream_iterator<typename iterator_traits<InputIter1>::value_type>(s, "n"),
average<typename iterator traits<InputIter1>::value_type>()); // Ошибка?
}
Многие компиляторы принимают этот код, но по Стандарту C++ он считается недопустимым. Дело в том, что теоретически может существовать другой шаблон функции с именем average, вызываемый с одним параметром-типом. В этом случае выражение average<typename iterator_traits<InputIter1>::value_type> становится неоднозначным, поскольку непонятно, какой шаблон в нем упоминается. В конкретном примере неоднозначность отсутствует, но некоторые компиляторы на вполне законном основании все равно отвергают этот код. Решение основано на использовании объекта функции:
template<typename FPType>
struct Average:
public binary_function<FPType, FPType, FPType> { // См. совет 40
FPType operator()(FPType val1, FPType val2) const {
return average(val1, val2);
}
};
template<typename InputIter1, typename InputIter2>
void writeAverages(InputIter1 begin1, InputIter1 end1,
InputIter2 begin2, ostream& s) {
transform(begin1, end1, begin2,
ostream_iterator<typename iterator_traits<InputIter1>::value_type>(s, "n"),
Average<typename iterator_traits<InputIter1>::value_type());
}
Новая версия должна приниматься любым компилятором. Более того, вызовы Average::operator() внутри transform допускают подстановку кода, что не относится к экземплярам приведенного выше шаблона average, поскольку average является шаблоном функции, а не объекта функции.
Таким образом, преимущество объектов функций в роли параметров алгоритмов не сводится к простому повышению эффективности. Объекты функций также обладают большей надежностью при компиляции кода. Бесспорно, «настоящие» функции очень важны, но в области эффективного программирования в STL объекты функций часто оказываются полезнее.
Совет 47. Избегайте «нечитаемого» кода
Допустим, имеется вектор vector<int>. Из этого вектора требуется удалить все элементы, значение которых меньше х, но оставить элементы, предшествующие последнему вхождению значения, не меньшего у. В голову мгновенно приходит следующее решение:
vector<int> v;
int х, у;
…
v.erase(
remove_if(find_if(v.rbegin(), v.rend(),
bind2nd(greater_equal<int>(), y)).base(),
v.end(),
bind2nd(less<int>(),x)),
v.end());
Всего одна команда, и задача решена. Все просто и прямолинейно. Никаких проблем. Правда?
Не будем торопиться с выводами. Считаете ли вы приведенный код логичным и удобным в сопровождении? «Нет!» — воскликнет большинство программистов C++ с ужасом и отвращением. «Да!» — скажут считанные единицы с явным удовольствием. В этом и заключается проблема. То, что один программист считает выразительной простотой, другому представляется адским наваждением.
Насколько я понимаю, приведенный выше фрагмент вызывает беспокойство по двум причинам. Во-первых, он содержит слишком много вызовов функций. Чтобы понять, о чем идет речь, приведу ту же команду, в которой имена функций заменены обозначениями fn:
v.f1(f2(f3(v.f4(), v.f5(),f6(f7(), y)).f8(), v.f9(), f6(f10(), x)), v.f9());
Такая запись выглядит неестественно усложненной, поскольку из нее убраны отступы, присутствующие в исходном примере. Можно уверенно сказать, что большинство программистов C++ сочтет, что двенадцать вызовов десяти разных функций в одной команде — это перебор. Но программисты с опытом работы на функциональных языках типа Scheme могут считать иначе. По своему опыту могу сказать, что почти все программисты, которые просматривали этот фрагмент без малейших признаков удивления, имели основательный опыт программирования на функциональных языках. У большинства программистов C++ такой опыт отсутствует, так что если ваши коллеги не привыкли к многоуровневым вложениям вызовов функций, конструкции вроде предыдущего вызова erase будут приводить их в замешательство.
Второй недостаток приведенного кода заключается в том, что для его понимания нужно хорошо знать STL. В нем встречаются менее распространенные _if-формы алгоритмов find и remove, обратные итераторы (см. совет 26), преобразования reverse_iterator в iterator (см. совет 28), bind2nd и анонимные объекты функций, а также идиома erase-remove (см. совет 32). Опытный программист STL разберется в этой комбинации без особого труда, но гораздо больше будет таких, кто надолго задумается над ней. Если ваши коллеги далеко продвинулись в изучении STL, присутствие erase, remove_if, find_if, base и bind2nd в одной команде вполне допустимо, но если вы хотите, чтобы ваша программа была понятна программисту C++ со средним уровнем подготовки, я рекомендую разделить эту команду на несколько фрагментов.
Ниже приведен один из возможных вариантов (комментарии приводятся не только для книги — я бы включил их и в программу).
typedef vector<int>::iterator VecIntIter;
// Инициализировать angeBegin первым элементом v, большим или равным
// последнему вхождению у. Если такой элемент не существует, rangeBegin
// инициируется значением v.begin()
VecIntIter rangeBegin = find_if(v.rbegin(), v.rend(),
bind2nd(greater_equal<int>(), y)).base();
// Удалить от rangeBegin до v.end все элементы со значением, меньшим х
v.erase(remove_if(rangeBegin, v.end(), bind2nd(less<int>(), x)), v.end());
Возможно, даже этот вариант кое-кого смутит, поскольку он требует понимания идиомы erase-remove, но при наличии комментариев в программе и хорошего справочника по STL (например, «The C++ Standard Library» [3] или web-сайта SGI [21]) каждый программист C++ без особых усилий разберется, что же происходит в программе.
Обратите внимание: в процессе модификации я не отказался от использования алгоритмов и не попытался заменить их циклами. В совете 43 объясняется, почему алгоритмы обычно предпочтительнее циклов, и приведенные аргументы действуют и в этом случае. Основная цель при программировании заключается в создании кода, понятного как для компилятора, так и для читателя-человека, и обладающего приемлемым быстродействием. Алгоритмы почти всегда лучше подходят для достижения этой цели. Тем не менее, совет 43 также объясняет, почему интенсивное использование алгоритмов естественным образом приводит к частому вложению вызовов функций и использованию адаптеров функторов. Вернемся к постановке задачи, с которой начинается настоящий совет.
Допустим, имеется вектор vector<int>. Из этого вектора требуется удалить все элементы, значение которых меньше x, но оставить элементы, предшествующие последнему вхождению значения, не меньшего y.
Нетрудно придти к общей схеме решения:
• поиск последнего вхождения значения в векторе требует применения find или find_if с обратными итераторами;
• удаление элементов требует erase или идиомы erase-remove.
Объединяя эти две идеи, мы получаем следующий псевдокод, где «нечто» обозначает код, который еще не был наполнен смысловым содержанием:
v.erase(remove_if(find_if(v.rbegin(), v.rend(), нечто).base(),
v.end(), нечто)), v.end());
При наличии такой схемы рассчитать, что же кроется за «нечто», совсем несложно. Вы не успеете опомниться, как придете к решению из исходного примера. Во время написания программы подобные решения выглядят вполне логичными, поскольку в них отражается последовательное применение базовых принципов (например, идиомы erase-remove плюс использование find с обратными итераторами). К сожалению, читателю вашей программы будет очень трудно разобрать готовый продукт на те идеи, из которых он был собран. «Нечитаемый» код легко пишется, но разобраться в нем трудно.
