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

Все вполне логично: два значения эквивалентны (по отношению к некоторому критерию упорядочения), если ни одно из них не предшествует другому в соответствии с данным критерием.

В общем случае функцией сравнения для ассоциативного контейнера является не оператор < или даже less, а пользовательский предикат (см. совет 39). Каждый стандартный ассоциативный контейнер предоставляет свой предикат сортировки через функцию key_comp, поэтому два объекта x и y имеют эквивалентные значения по отношению к критерию сортировки ассоциативного контейнера c, если выполняется следующее условие:

!c.key_comp(x, y) && !c.key_comp(y, x) // х не предшествует у

// в порядке сортировки с,

// а у не предшествует х

Выражение !c.key_comp(x,y) выглядит устрашающе, но стоит понять, что c.key_comp возвращает функцию (или объект функции), как все затруднения исчезают. Перед нами простой вызов функции (или объекта функции), возвращаемой key_comp, которой передаются аргументы x и y. Затем вычисляется логическое отрицание результата. Функция с.keycomp(х, у) возвращает true лишь в том случае, если x предшествует y в порядке сортировки, поэтому выражение !с.key_comp(х, у) истинно только в том случае, если x не предшествует y в порядке сортировки c.

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

struct CiStringCompare:                // Класс сравнения строк

public                                 // без учета регистра символов;

binary_function{ // описание базового класса

                                       // приведено в совете 40

bool operator (const string& lhs, const string& rhs) const {

 return ciStringCompare(lhs, rhs); // Реализация ciStringCompare

                                   // приведена в совете 35

 }

};

При наличии CiStringCompare контейнер set, игнорирующий регистр символов, создается очень просто:

set ciss;

Теперь при вставке строк «Persephone» и «persephone» в множество будет включена только первая строка, поскольку вторая считается эквивалентной:

ciss.insert("Persephone"); // В множество включается новый элемент

ciss.insert("persephone"); // Эквивалентный элемент не включается

Если теперь провести поиск строки «persephone» функцией set::find, результат будет успешным:

if(ciss.find("persephone")!=ciss.end)... // Элемент найден

Но если воспользоваться внешним алгоритмом find, поиск завершается неудачей:

if (find(ciss.begin, ciss.end,

 "persephone")!=ciss.end)… // Элемент отсутствует

Дело в том, что строка «persephone» эквивалентна«Persephone» (по отношению к функтору сравнения CIStringCompare), но не равна ей (поскольку string("persephone") !=string("Persephone")). Приведенный пример поясняет одну из причин, по которой в соответствии с советом 44 рекомендуется использовать функции контейнеров (set::find) вместо их внешних аналогов (find).

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