size_t fillString(char *pArray, sizet arraySize);
vector<char> vc(maxNumChars); // Создать vector, емкость которого
// равна maxNumChars
size_t charsWritten = fillString(&vc[0],vc.size()); // Заполнить vc
// вызовом fillString
string s(vc.begin(), vc.begin()+charsWritten); // Скопировать данные
// из vc в s интервальным
// конструктором (совет 5)
Собственно, сам принцип сохранения данных функцией API в vector и их последующего копирования в нужный контейнер STL работает всегда:
size_t fillArray(double *pArray, size_t arraySize); // См. ранее
vector<double> vd(maxNumDoubles);// Также см. ранее
vd.resize(fillArray(&vd[0], vd.size());
deque<double> d(vd.begin(), vd.end()); // Копирование в deque
list<double> l(vd.begin(), vd.end()); // Копирование в list
set<double> s(vd.begin(), vd.end()); // Копирование в set
Более того, этот фрагмент подсказывает, как организовать передачу данных из других контейнеров STL, кроме vector и string, функциям C. Для этого достаточно скопировать данные контейнера в vector и передать его при вызове:
void doSomething(const int* pints, size_t numInts); // Функция C (см. ранее)
set<int> intSet; // Множество, в котором
… // хранятся передаваемые
// данные
vector<int> v(intSet.begin(), intSet.end());// Скопировать данные
// из set в vector
if (!v.empty()) doSomething(&v[0], v.size()); // Передать данные
// функции С
Вообще говоря, данные также можно скопировать в массив и передать их функции C, но зачем это нужно? Если размер контейнера не известен на стадии компиляции, память придется выделять динамически, а в совете 13 объясняется, почему вместо динамических массивов следует использовать vector.
Совет 17. Используйте «фокус с перестановкой» для уменьшения емкости
Предположим, вы пишете программу для нового телешоу «Бешеные деньги». Информация о потенциальных участниках хранится в векторе:
class Contestant {…};
vector<Contestant> contestants;
При объявлении набора участников заявки сыплются градом, и вектор быстро заполняется элементами. Но по мере отбора перспективных кандидатов относительно небольшое количество элементов перемещается в начало вектора (вероятно, вызовом partial_sort или partition — см. совет 31), а неудачники удаляются из вектора (как правило, при помощи интервальной формы erase — см. совет 5). В результате удаления длина вектора уменьшается, но емкость остается прежней. Если в какой-то момент времени вектор содержал данные о 100 000 кандидатов, то его емкость останется равной 100 000, даже если позднее количество элементов уменьшится до 10.
Чтобы вектор не удерживал ненужную память, необходимы средства, которые бы позволяли сократить емкость от максимальной до используемой в настоящий момент. Подобное сокращение емкости обычно называется «сжатием по размеру». Сжатие по размеру легко программируется, однако код — как бы выразиться поделикатнее? — выглядит недостаточно интуитивно. Давайте разберемся, как он работает.
Усечение лишней емкости в векторе contestants производится следующим образом:
vector<Contestant>(contestants).swap(contestants);
Выражение vector<Contestant>(contestants) создает временный вектор, содержащий копию contestants; основная работа выполняется копирующим конструктором vector. Тем не менее, копирующий конструктор vector выделяет ровно столько памяти, сколько необходимо для хранения копируемых элементов, поэтому временный вектор не содержит лишней емкости. Затем содержимое вектора contestants меняется местами с временным вектором функцией swap. После завершения этой операции в contestants оказывается содержимое временного вектора с усеченной емкостью, а временный вектор содержит «раздутые» данные, ранее находившиеся в contestants. В этот момент (то есть в конце команды) временный вектор уничтожается, освобождая память, ранее занимаемую вектором contestants.
Аналогичный прием применяется и по отношению к строкам:
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++. В частности, в этих требованиях говорится, что если 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[] должна вернуть несуществующую ссылку на отдельный бит.
