Эффективное использование STL

Мейерс Скотт

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

с обратными итераторами). К сожалению, читателю вашей программы будет очень трудно разобрать готовый продукт на те идеи, из которых он был собран. «Нечитаемый» код легко пишется, но разобраться в нем трудно.

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

Банальный факт из области программирования: код чаще читается, чем пишется. Хорошо известно также, что на сопровождение программы уходит значительно больше времени, чем на ее разработку. Если программу нельзя прочитать и понять, ее нельзя и успешно сопровождать, а такие программы вообще никому не нужны. Чем больше вы работаете с STL, тем увереннее себя чувствуете и тем сильнее хочется использовать вложенные вызовы функций и создавать объекты функций «на лету». В этом нет ничего плохого, но всегда следует помнить, что написанную сегодня программу завтра придется кому-то читать — может быть, даже вам. Приготовьтесь к этому дню.