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

ЖАНРЫ

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

Лексикографический критерий сравнения может оказаться неподходящим для некоторых специфических ситуаций. Более того, единого критерия вообще не существует — например, имена людей и географические названия иногда сортируются по разным критериям. С другой стороны, в большинстве случаев лексикографический критерий подходит, поэтому он был заложен в основу механизма строковых сравнений в C++. Строка представляет собой последовательность символов. Если объекты 

x
и 
y
относятся к типу
std::string
, то выражение
x<y
эквивалентно выражению

std::lexicographical_compare(x.begin, x.end, y.begin, y.end)

В приведенном выражении алгоритм

lexicographical_compare
сравнивает отдельные символы оператором
<
,
однако существует другая версия
lexicographical_compare
, позволяющая задать пользовательский критерий сравнения символов. Она вызывается с пятью аргументами вместо четырех; в последнем аргументе передается объект функции, двоичный предикат, определяющий, какой из двух символов предшествует другому. Таким образом, для сравнения строк без учета регистра на базе
lexicographical_compare
достаточно объединить этот алгоритм с объектом функции, игнорирующим различия в регистре символов.

Распространенный принцип сравнения двух символов без учета регистра заключается в том, чтобы преобразовать оба символа к верхнему регистру и сравнить результаты. Ниже приведена тривиальная формулировка этой идеи в виде объекта функции C++ с использованием хорошо известной функции toupper из стандартной библиотеки C:

struct lt_nocase:

 public std::binary_function<char, char, bool> {

 bool operator(char x, char y) const {

return std::toupper(static_cast<unsigned char>(x))<

std::toupper(static_cast<unsigned char>(y));

 }

};

«У каждой сложной задачи есть решение простое, элегантное и… неправильное». Авторы книг C++ обожают этот класс за простоту и наглядность. Я тоже неоднократно использовал его в своих книгах. Он почти правилен, и все-таки не совсем, хотя недостаток весьма нетривиален. Следующий пример выявляет этот недостаток:

int main {

 const char* s1 = "GEW\334RZTRAMINER";

 const char* s2 = "gew\374rztraminer";

 printf("s1=%s, s2=%s\n", s1, s2);

 printf("s1<s2:%s\n",

std::lexicographical_compare(s1, s1+14, s2, s2+14, lt_nocase)

?"true":"false");

}

Попробуйте запустить эту программу в своей системе. На моем компьютере (Silicon Graphics О2 с системой IRIX 6.5) результат выглядел так:

s1=GEW"URZTRAMINER,s2=gew"urztraminer

s1<s2:true

Странно… Разве при сравнении без учета регистра «GEW"URZTRAMINER» и «gew"urztraminer» не должны быть равными? И еще возможен вариант с небольшой модификацией: если перед командой printf вставить строку

setlocale(LC_ALL, "de");

результат неожиданно изменяется:

s1=GEW"URZTRAMINER,s2=gew"urztraminer

s1<s2:false

Задача сравнения строк без учета регистра сложнее, чем кажется сначала. Работа элементарной на первый взгляд программы в огромной степени зависит от того, о чем многие из нас предпочли бы забыть. Речь идет о локальном контексте.

Локальный контекст

Символьный тип

char
в действительности представляется самым обычным целым числом. Это число можно интерпретировать как символ, но такая интерпретация ни в коем случае не является универсальной. Что должно соответствовать конкретному числу — буква, знак препинания, непечатаемый управляющий символ?

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

isalpha
проверяет, является ли символ буквой, а функция
toupper
переводит символы нижнего регистра в верхний регистр и оставляет без изменений буквы верхнего регистра и символы, не являющиеся буквами. Подобная классификация символов определяется особенностями культурной и лингвистической среды. В английском языке действуют одни правила, по которым буквенные символы отличаются от «не буквенных»,
в шведском — другие и т. д. Преобразование из нижнего регистра в верхний имеет один смысл в латинском алфавите, другой — в кириллице, и вообще не имеет смысла в иврите.

По умолчанию функции обработки символов работают с кодировкой, подходящей для простого английского текста. Символ '\374' не изменяется функцией

toupper
, поскольку он не считается буквой; в некоторых системах при выводе он имеет вид "u, но для библиотечной функции C, работающей с английским текстом, это несущественно. В кодировке ASCII нет символа "u. Команда

setlocale(LC_ALL, "de");

сообщает библиотеке C о переходе на немецкие правила (по крайней мере в системе IRIX — имена локальных контекстов не стандартизованы). В немецком языке есть символ "u, поэтому функция

toupper
преобразует "u в "U.

У любого нормального программиста этот факт вызывает обоснованное беспокойство. Оказывается, простая функция

toupper
, вызываемая с одним аргументом, зависит еще и от глобальной переменной — хуже того, от скрытой глобальной переменной. Это приводит к стандартной проблеме: на работу функции, использующей
toupper
, теоретически может повлиять любая другая функция во всей программе.

При использовании

toupper
для сравнения строк без учета регистра результат может быть катастрофическим. Предположим, у вас имеется алгоритм, получающий отсортированный, список (скажем,
binary_search
); все работает нормально, как вдруг новый локальный контекст на ходу изменяет порядок сортировки. Такой код не подходит для многократного использования. Более того, он вообще едва ли способен принести практическую пользу. Его нельзя применить в библиотеке — библиотеки используются множеством разных программ, не только теми, которые никогда не вызывают функцию
setlocalе
. Возможно, вам удастся применить его в какой-нибудь большой программе, но это приводит к проблемам сопровождения. Возможно, вам удастся проследить за тем, чтобы все остальные модули не вызывали setlocalе, но как предотвратить вызов
setlocalе
модулем, который появится только в следующей версии программы?

В языке C приемлемого решения этой проблемы не существует. Библиотека C использует единственный локальный контекст, и с этим ничего не поделаешь. Решение существует в языке C++.

Локальные контексты в C++

В стандартной библиотеке C++ локальный контекст не является глобальной структурой данных, запрятанной где-то в недрах реализации библиотеки. Это объект типа

std::locale
, который можно создать и передать его другой функции, как любой другой объект. Пример создания объекта для стандартного локального контекста:

std::locale L = std::locale::classic;

Локальный контекст немецкого языка создается командой

std::locale L("de");

Имена локальных контекстов, как и в библиотеке C, не стандартизованы. Список имен локальных контекстов, доступных в вашей реализации, следует искать в документации.

Локальные контексты C++ делятся на фасеты (

facets
), связанные с разными аспектами интернационализации. Для извлечения заданного фасета из объекта локального контекста используется функция
std::use_facet
[6] . Фасет
ctype
отвечает за классификацию символов, в том числе и преобразования типа. Если
c1
и
c2
относятся к типу
char
, следующий фрагмент сравнивает их без учета регистра по правилам локального контекста
L
.

6

Внимание: в шаблоне функции

use_facet
параметр шаблона присутствует только в типе возвращаемого значения, но не в аргументах. При обращении к нему используется языковое средство, называ-емоеявяьш заданием аргументов шаблона, которое не поддерживается некоторыми компиляторами C++. Если ваш компилятор принадлежит к их числу, возможно, авторы реализации библиотеки предусмотрели обходное решение, которое позволяет использовать
use_facet
другим способом.

Поделиться с друзьями: