Книга: Эффективное использование STL
Совет 18. Избегайте vector
Совет 18. Избегайте vector<bool>
Vector<bool> как контейнер STL обладает лишь двумя недостатками. Во-первых, это вообще не контейнер STL. Во-вторых, он не содержит bool
.
Объект не становится контейнером STL только потому, что кто-то назвал его таковым — он становится контейнером STL лишь при соблюдении всех требований, изложенных в разделе 23.1 Стандарта C++. В частности, в этих требованиях говорится, что если c
— контейнер объектов типа T
, поддерживающий оператор []
, то следующая конструкция должна нормально компилироваться:
T *р = &с[0];// Инициализировать T* адресом данных,
// возвращаемых оператором []
Иначе говоря, если оператор []
используется для получения одного из объектов T
в Container<T>
, то указатель на этот объект можно получить простым взятием его адреса (предполагается, что оператор &
типа 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[]
должна возвращать значение типа T&
. Если бы контейнер 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, тем глубже вы осознаете эту истину. Уверяю вас, наступит день, когда написанный вами шаблон будет работать лишь в том случае, если получение адреса элемента контейнера дает указатель на тип элемента; и когда этот день придет, вы наглядно ощутите разницу между контейнером и почтиконтейнером.
Спрашивается, почему же vector<bool>
присутствует в Стандарте, если это не контейнер? Отчасти это связано с одним благородным, но неудачным экспериментом, но позвольте мне ненадолго отложить эту тему и заняться более насущным вопросом. Итак, от vector<bool>
следует держаться подальше, потому что это не контейнер — но что же делать, когда вам действительно понадобитсявектор логических величин?
В стандартную библиотеку входят два альтернативных решения, которые подходят практически для любых ситуаций. Первое решение — deque<bool>
. Контейнер deque
обладает практически всеми возможностями vector
(за исключением разве что reserve
и capacity
), но при этом deque<bool>
является полноценным контейнером STL, содержащим настоящие значения bool
. Конечно, внутренняя память deque
не образует непрерывный блок, поэтому данные deque<bool>
не удастся передать функции C, получающей массив bool
(см. совет 16), но это не удалось бы сделать и с vector<bool>
из-за отсутствия переносимого способа получения данных vector<bool>
. (Прием, продемонстрированный для vector
в совете 16, не компилируется для vector<bool>
, поскольку он зависит от возможности получения на тип элемента, хранящегося в векторе, — как упоминалось выше, vector<bool>
не содержит bool
.)
Второй альтернативой для vector<bool>
является bitset
. Вообще говоря, bitset
не является стандартным контейнером STL, но входит в стандартную библиотеку C++. В отличие от контейнеров STL, размер bitset
(количество элементов) фиксируется на стадии компиляции, поэтому операции вставки-удаления элементов не поддерживаются. Более того, поскольку bitset
не является контейнером STL, в нем отсутствует поддержка итераторов. Тем не менее bitset
, как и vector<bool>
, использует компактное представление каждого элемента одним битом, поддерживает функцию flip
контейнера vector<bool>
и ряд других специальных функций, имеющих смысл в контексте битовых множеств. Если вы переживете без итераторов и динамического изменения размеров, вероятно, bitset
хорошо подойдет для ваших целей.
А теперь вернемся к благородному, но неудачному эксперименту, из-за которого появился «псевдоконтейнер» vector<bool>
. Я уже упоминал о том, что промежуточные объекты часто используются при программировании на C++. Члены Комитета по стандартизации C++ знали об этом, поэтому они решили создать vector<bool>
как наглядный пример контейнера, доступ к элементам которого производится через промежуточные объекты. Предполагалось, что при наличии такого примера в Стандарте у программистов появится готовый образец для построения собственных аналогов.
В итоге выяснилось, что создать контейнер с промежуточными объектами, удовлетворяющий всем требованиям к контейнеру STL, невозможно. Так или иначе, следы этой неудачной попытки сохранились в Стандарте. Можно долго гадать, почему vector<bool>
был сохранен, но с практической точки зрения это несущественно. Главное — помните, что vector<bool>
не удовлетворяет требованиям к контейнерам STL, что им лучше не пользоваться и что существуют альтернативные структуры данных deque<bool>
и bitset
, почти всегда способные заменить vector<bool>
.
- Совет 13. Используйте vector и string вместо динамических массивов
- Совет 14. Используйте reserve для предотвращения лишних операций перераспределения памяти
- Совет 15. Помните о различиях в реализации string
- Совет 16. Научитесь передавать данные vector и string функциям унаследованного интерфейса
- Совет 17. Используйте «фокус с перестановкой» для уменьшения емкости
- Совет 18. Избегайте vector
- Совет 47. Избегайте «нечитаемого» кода
- Контейнеры vector и string
- Глава 14 Советы хакера
- 4.15. Советы по конфигурированию Firewall
- 7.7.3. Секреты и советы
- Советы покупателям
- Несколько советов обеспокоенным администраторам
- Совет 48. Всегда включайте нужные заголовки
- 14.12. Короткие советы
- Советы для эффективного рисования
- Советы по навигации в Сети
- Совет 5. Используйте интервальные функции вместо одноэлементных