Эффективное использование STL, Мейерс Скотт

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

на обложку

Мейерс Скотт

Шрифт:

Аналогичный прием применяется и по отношению к строкам:

string s; // Создать большую строку и удалить из нее

… // большую часть символов

string(s).swap(s); // Выполнить "сжатие по размеру" с объектом s

Я не могу предоставить стопроцентной гарантии того, что этом прием действительно удалит из контейнера лишнюю емкость. Авторы реализаций при желании могут намеренно выделить в контейнерах

vector

string

лишнюю память, и иногда они так и поступают. Например, контейнер может обладать минимальной емкостью или же значения емкости

vector/string

могут ограничиваться степенями 2 (по собственному опыту могу сказать, что подобные аномалии чаще встречаются в реализациях

string

, нежели в реализациях

vector

. За примерами обращайтесь к совету 15). Таким образом, «сжатие по размеру» следует понимать не как «приведение к минимальной емкости», а как «приведение к минимальной емкости, допускаемой реализацией для текущего размера контейнера». Впрочем, это лучшее, что вы можете сделать (не считая перехода на другую реализацию STL), поэтому «сжатие по размеру» для контейнеров

vector

string

фактически эквивалентно «фокусу с перестановкой».

Кстати говоря, одна из разновидностей «фокуса с перестановкой» может использоваться для очистки контейнера с одновременным сокращением емкости до минимальной величины, поддерживаемой вашей реализацией. Для этого в перестановке используется временный объект

vector

или

string

, содержимое которого создается конструктором по умолчанию:

vector<Contestant> v;

string s;

… // Использовать v и s

vector<Contestant>.swap(v); // Очистить v с уменьшением емкости

string.swap(s); // Очистить s с уменьшением емкости

Остается сделать последнее замечание, относящееся к функции

swap

в целом. Перестановка содержимого двух контейнеров также приводит к перестановке их итераторов, указателей и ссылок. Итераторы, указатели и ссылки, относившиеся к элементам одного контейнера, после вызова

swap

остаются действительными и указывают на те же элементы — но в другом контейнере.

Совет 18. Избегайте vector<bool>

Vector<bool> как контейнер STL обладает лишь двумя недостатками. Во-первых, это вообще не контейнер STL. Во-вторых, он не содержит

bool

Объект не становится контейнером STL только потому, что кто-то назвал его таковым — он становится контейнером STL лишь при соблюдении всех требований, изложенных в разделе 23.1 Стандарта C++. В частности, в этих требованиях говорится, что если

— контейнер объектов типа

, поддерживающий оператор

[]

, то следующая конструкция должна нормально компилироваться:

T *р = &с[0];// Инициализировать T* адресом данных,

// возвращаемых оператором []

Иначе говоря, если оператор

[]

используется для получения одного из объектов

Container<T>

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

типа

не был перегружен извращенным способом). Следовательно, чтобы

vector<bool>

был контейнером, следующий фрагмент должен компилироваться:

vector<bool> v;

bool *pb = &v[0]; // Инициализировать bool* адресом результата,

// возвращаемого оператором vector<bool>::operator[]

Однако приведенный фрагмент компилироваться не будет. Дело в том, что

vector<bool>

— псевдоконтейнер, содержащий не настоящие логические величины

bool

, а их представления, упакованные для экономии места. В типичной реализации каждая псевдовеличина «

bool

», хранящаяся в псевдовекторе, занимает один бит, а восьмибитовый байт представляет восемь «

bool

». Во внутреннем представлении

vector<bool>

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

Битовые поля, как и

bool

, принимают только два возможных значения, но между «настоящими» логическими величинами и маскирующимися под них битовыми полями существует принципиальное различие. Создать указатель на реальное число

bool

можно, но указатели на отдельные биты запрещены.

Ссылки на отдельные биты тоже запрещены, что представляет определенную проблему для дизайна интерфейса

vector<bool>

, поскольку функция

vector<T>::operator[]

должна возвращать значение типа

. Если бы контейнер

vector<bool>

действительно содержал

bool

, этой проблемы не существовало бы, но вследствие особенностей внутреннего представления функция

vector<T>::operator[]

должна вернуть несуществующую ссылку на отдельный бит.

Чтобы справиться с этим затруднением, функция

vector<T>::operator[]

возвращает объект, который имитируетссылку на отдельный бит — так называемый промежуточный объект. Для использования STL не обязательно понимать, как работают промежуточные объекты, но вообще это весьма полезная идиома C++. Дополнительная информация о промежуточных объектах приведена в совете 30 «More Effective C++», а также в разделе «Паттерн Proxy» книги «Приемы объектно-ориентированного проектирования» [6]. На простейшем уровне

vector<bool>

выглядит примерно так:

template <typename Allocator>

vector<bool, Allocator> {

public:

class reference {…};// Класс, генерирующий промежуточные

// объекты для ссылок на отдельные биты

reference operator[](size_type n); // operator[] возвращает

… // промежуточный объект

};

Теперь понятно, почему следующий фрагмент не компилируется:

vector<bool> v;

bool *pb=&v[0]; // Ошибка! Выражение в правой части относится к типу

// vector<bool>::reference*, а не bool*

А раз фрагмент не компилируется,

vector<bool>

не удовлетворяет требованиям к контейнерам STL. Да, специфика

vector<bool>

особо оговорена в Стандарте; да, этот контейнер почтиудовлетворяет требованиям к контейнерам STL, но «почти» не считается. Чем больше вы напишете шаблонов, предназначенных для работы с STL, тем глубже вы осознаете эту истину. Уверяю вас, наступит день, когда написанный вами шаблон будет работать лишь в том случае, если получение адреса элемента контейнера дает указатель на тип элемента; и когда этот день придет, вы наглядно ощутите разницу между контейнером и почтиконтейнером.