Книги
чёрным по белому
Главное меню
Главная О нас Добавить материал Поиск по сайту Карта книг Карта сайта
Книги
Археология Архитектура Бизнес Биология Ветеринария Военная промышленность География Геология Гороскоп Дизайн Журналы Инженерия Информационные ресурсы Искусство История Компьютерная литература Криптология Кулинария Культура Лингвистика Математика Медицина Менеджмент Металлургия Минералогия Музыка Научная литература Нумизматика Образование Охота Педагогика Политика Промышленные производства Психология Путеводители Религия Рыбалка Садоводство Саморазвитие Семиотика Социология Спорт Столярное дело Строительство Техника Туризм Фантастика Физика Футурология Химия Художественная литература Экология Экономика Электроника Энергетика Этика Юриспруденция
Новые книги
Цуканов Б.И. "Время в психике человека" (Медицина)

Суворов С. "Танк Т-64. Первенец танков 2-го поколения " (Военная промышленность)

Нестеров В.А. "Основы проэктирования ракет класса воздух- воздух и авиационных катапульных установок для них" (Военная промышленность)

Фогль Б. "101 вопрос, который задала бы ваша кошка своему ветеринару если бы умела говорить" (Ветеринария)

Яблоков Н.П. "Криминалистика" (Юриспруденция)
Реклама

Эффективное использование STL. Библиотека программиста - Мейерс С.

Мейерс С. Эффективное использование STL. Библиотека программиста — Спб.: Питер , 2002. — 224 c.
ISBN 5-94723-382-7
Скачать (прямая ссылка): effektivnoeispolzovaniestlbibliote2002.djvu
Предыдущая << 1 .. 38 39 40 41 42 43 < 44 > 45 46 47 48 49 50 .. 114 >> Следующая

c.key_comp() возвращает функцию (или объект функции), как все затруднения
исчезают. Перед нами простой вызов функции (или объекта функции),
возвращаемой key_comp, которой передаются аргументы х и у. Затем
вычисляется логическое отрицание результата. Функция с. keycomp () (х, у)
возвращает true лишь в том случае, если х предшествует у в порядке
сортировки, поэтому выражение ! с. key_comp () (х, у) истинно только в
том случае, если х не предшествует у в порядке сортировки с.
Чтобы вы лучше осознали принципиальный характер различий между равенством
и эквивалентностью, рассмотрим пример - контейнер set<string> без учета
регистра символов, то есть контейнер set<string>, в котором функция
сравнения игнорирует регистр символов в строках. С точки зрения такой
функции строки "STL" и "stL" эквивалентны. Пример реализации функции
ciStringCompare, игнорирующей регистр символов, приведен в совете 35,
однако set требуется тип функции сравнения, а не сама функция. Чтобы
заполнить этот пробел, мы пишем класс функтора с оператором О, вызывающим
ciStringCompare:
struct CiStringCompare: // Класс сравнения строк
public // без учета регистра символов;
binary_function<string.string.bool>{ // описание базового класса
// приведено в совете 40
bool operatorO (const strings lhs,
const strings rhs) const
{
return ciStringCompare(lhs.rhs); // Реализация ciStringCompare
// приведена в совете 35
}
}:
При наличии CiStringCompare контейнер set<string>, игнорирующий регистр
символов, создается очень просто:
set<string.CIStringCompare> ciss:
Теперь при вставке строк "Persephone" и "persephone" в множество будет
включена только первая строка, поскольку вторая считается эквивалентной:
ciss.insert("Persephone"): // В множество включается новый элемент
ciss.insert("persephone"): // Эквивалентный элемент не включается
86 Глава 3 • Ассоциативные контейнеры
Если теперь провести поиск строки "persephone" функцией set: :find,
результат будет успешным:
if(ciss.find("persephone")!=ciss.end())... // Элемент найден
Но если воспользоваться внешним алгоритмом find, поиск завершается
неудачей:
if(find(ciss.begin(). ciss.endO.
"persephone")!=ciss.end())... // Элемент отсутствует
Дело в том, что строка "persephone" эквивалентна "Persephone" (по
отношению к функтору сравнения ClStringCompare), но неравна ей (поскольку
string ("persephone") !=string( "Persephone")). Приведенный пример
поясняет одну из причин, по которой в соответствии с советом 44
рекомендуется использовать функции контейнеров (set:: find) вместо их
внешних аналогов (find).
Возникает вопрос - почему же в работе стандартных ассоциативных
контейнеров используется понятие эквивалентности, а не равенства? Ведь
большинству программистов равенство кажется интуитивно более понятным,
чем эквивалентность (в противном случае данный совет был бы лишним). На
первый взгляд ответ кажется простым, но чем дольше размышляешь над этим
вопросом, тем менее очевидным он становится.
Стандартные ассоциативные контейнеры сортируются, поэтому каждый
контейнер должен иметь функцию сравнения (по умолчанию less),
определяющую порядок сортировки. Эквивалентность определяется в контексте
функции сравнения, поэтому клиентам стандартных ассоциативных контейнеров
остается лишь задать единственную функцию сравнения. Если бы
ассоциативные контейнеры при сравнении объектов использовали критерий
равенства, то каждому ассоциативному контейнеру, помимо используемой при
сортировке функции сравнения, пришлось бы определять вторую функцию для
проверки равенства. Вероятно, по умолчанию функция сравнения вызывала бы
equal _to, но интересно заметить, что функция equal_to в STL не
используется в качестве стандартной функции сравнения. Когда в STL
возникает необходимость проверки равенства, по умолчанию просто
вызывается оператор =. В частности, именно так поступает внешний алгоритм
find.
Допустим, у нас имеется контейнер set2CF, построенный по образцу set -
"set с двумя функциями сравнения". Первая функция сравнения определяет
порядок сортировки элементов множества, а вторая используется для
проверки равенства. А теперь рассмотрим следующее объявление:
set2CF<string.ClStringCompare,equal_to<string> > S;
Контейнер s производит внутреннюю сортировку строк без учета регистра, но
с использованием интуитивного критерия равенства: две строки считаются
равными при совпадении их содержимого. Предположим, в s вставляются два
варианта написания строки "Persephone":
s. i nsert("Persephone");
s.i nsert("persephone");
Как поступить в этом случае? Если контейнер поймет, что "Persephone" !=
"persephone", и вставит обе строки в s, в каком порядке они должны
следовать?
Совет 20 87
Напомню, что функция сортировки эти строки не различает. Следует ли
вставить строки в произвольном порядке, добровольно отказавшись от
детерминированного порядка перебора содержимого контейнера?
Недетерминированный порядок перебора уже присущ ассоциативным контейнерам
Предыдущая << 1 .. 38 39 40 41 42 43 < 44 > 45 46 47 48 49 50 .. 114 >> Следующая