Объекты string занимают в 1-7 (по меньшей мере) раз больше памяти, чем указатели char*.

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

Объекты string могут совместно использовать данные о размере и емкости строки.

Объекты string могут поддерживать (или не поддерживать) распределители памяти уровня объекта.

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

Только не поймите меня превратно. Я считаю, что контейнер string является одним из важнейших компонентов стандартной библиотеки и рекомендую использовать его как можно чаще. Например, совет 13 посвящен возможности использования string вместо динамических символьных массивов. Но для эффективного использования STL необходимо разбираться во всем разнообразии реализаций string, особенно если ваша программа должна работать на разных платформах STL при жестких требованиях к быстродействию.

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

Совет 16. Научитесь передавать данные vector и string функциям унаследованного интерфейса

с момента стандартизации C+-I- в 1998 году элита C+-I- настойчиво подталкивает программистов к переходу с массивов на vector. Столь же открыто пропагандируется переход от указателей char* к объектам string. В пользу перехода имеются достаточно веские аргументы, в том числе ликвидация распространенных ошибок программирования (совет 13) и возможность полноценного использования всей мощи алгоритмов STL (совет 31).

Но на этом пути остаются некоторые препятствия, из которых едва ли не самым распространенным являются унаследованные интерфейсы языка С, работающие с массивами и указателями char* вместо объектов vector и string. Они существуют с давних времен, и если мы хотим эффективно использовать STL, придется как-то уживаться с этими пережитками прошлого .

К счастью, задача решается просто. Если у вас имеется vector v и вы хотите получить указатель на данные v, которые интерпретировались бы как массив, воспользуйтесь записью &v[0]. Для string s аналогичная запись имеет вид s.c str(). Впрочем, это не все - существуют некоторые ограничения (то, о чем в рекламе обычно пишется самым мелким шрифтом).

Рассмотрим следующее объявление:

vector<int> v:

Выражение v[0] дает ссылку на первый элемент вектора, соответственно &v[0] - указатель на первый элемент. В соответствии со Стандартом C-i-i- элементы vector

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

void doSomething(const int* pints. size t numlnts);

Передача данных должна происходить так:

doSomethi ng(&v[0],v.si ze());

Bo всяком случае, так должно быть. Остается лишь понять, что произойдет, если вектор v пуст. В этом случае функция v.sizeO вернет О, а &v[0] пытается получить указатель на несуществующий блок памяти с непредсказуемыми последствиями. Нехорошо. Более надежный вариант вызова выглядит так:

if (Iv.emptyO) {

doSomething(&v[0],v.size()):

Отдельные подозрительные личности утверждают, что &v[0] можно заменить на V. begi п (), поскольку begi п возвращает итератор, а для vector итератор в действительности представляет собой указатель. Во многих случаях это действительно так, но, как будет показано в совете 50, это правило соблюдается не всегда, и полагаться на него не стоит. Функция begin возвращает итератор, а не указатель, поэтому она никогда не должна использоваться для ползения указателя на данные vector. А если уж вам очень приглянулась запись v. begiп(), используйте конструкцию &*v.begin() - она вернет тот же указатель, что и &v[0], хотя это увеличивает количество вводимых символов и затрудняет работу людей, пытающихся разобраться в вашей программе. Если знакомые вам советуют использовать v.beginO вместо &v[0] - лучше смените круг общения.

Способ ползения указателя на данные контейнера, хорошо работающий для vector, недостаточно надежен для stri ng. Во-первых, контейнер stri ng не гарантирует хранения данных в непрерывном блоке памяти; во-вторых, внутреннее представление строки не обязательно завершается нуль-символом. По этим причинам в контейнере string предусмотрена функция c str, которая возвращает указатель на содержимое строки в формате С. Таким образом, передача строки s функции

void doSomething(const char *pString);

происходит так:

doSomething(s.c str());

Данное решение подходит и для строк нулевой длины. В этом случае c str возвращает указатель на нуль-символ. Кроме того, оно годится и для строк с внутренними нуль-символами, хотя в этом слзае doSometliing с большой вероятностью интерпретирует первый внутренний нуль-символ как признак конца строки. Присутствие внутренних нуль-символов несущественно для объектов stri ng, но не для функций С, использующих cliar*.

Вернемся к объявлениям doSometliing:

void doSomething(const int* pints. size t numlnts); void doSomething(const char *pString);

В обоих случаях передаются указатели на const. Функция С, ползающая данные vector или stri ng, читает их, не пытаясь модифицировать. Такой вариант наиболее безопасен. Для stri ng он неизбежен, поскольку не существует гарантии, что

c str вернет указатель на внутреннее представление строковых данных; функция может вернуть указатель на неизменяемую копию данных в формате С (если вас встревожила эффективность этих операций, не волнуйтесь - мне не известна ни одна современная реализация библиотеки, в которой бы использовалась данная возможность).

Vector предоставляет программисту чуть большую свободу действий. Передача V функции С, модифицирующей элементы v, обычно обходится без проблем, но вызванная функция не должна изменять количество элементов в векторе. Например, она не может создавать новые элементы в неиспользуемой памяти vector. Такие попытки приведут к нарушению логической целостности контейнера v, поскольку объект не будет знать свой правильный размер, и вызов функции V. size О возвратит неправильные результаты. А если вызванная функция попытается добавить новые данные в вектор, у которого текущий размер совпадает с емкостью (совет 14), произойдет сущий кошмар. Я даже не пытаюсь предугадать последствия, настолько они ужасны.

Вы обратили внимание на формулировку обычно обходится без проблем в предыдущем абзаце? Конечно, обратили. Некоторые векторы устанавливают для своих данных дополнительные ограничения, и при передаче вектора функции API, изменяющей его содержимое, вы должны проследить за тем, чтобы эти ограничения не были нарушены. Например, как объясняется в совете 23, сортируемые векторы часто могут рассматриваться в качестве разумной альтернативы для ассоциативных контейнеров, но при этом содержимое таких векторов должно оставаться правильно отсортированным. При передаче сортируемого вектора функции, способной изменить его содержимое, вам придется зитывать, что при возвращении из функции сортировка элементов может быть нарушена.

Если у вас имеется vector, который должен инициализироваться внутри функции С, можно воспользоваться структурной совместимостью vector с массивами и передать функции указатель на блок элементов вектора:

Функция fillArray получает указатель на массив.

содержащий не более arraySize чисел типа double.

и записывает в него данные. Возвращаемое количество записанных

чисел заведомо не превышает maxNumDoubles.

size t fillArray(double *pArray, size t arraySize);

vector<double> vd(maxNumDoubles); Создать vector, емкость которого

равна maxNumDoubles

vd.resize(finArray(&vd[0],vd.size())): Заполнить vd вызовом

функции fillArray. после чего

изменить размер по количеству

записанных элементов

Данный способ подходит только для vector, поскольку только этот контейнер заведомо совместим с массивами по структуре памяти. Впрочем, задача инициализации string функцией С тоже решается достаточно просто. Данные, возвращаемые функцией, заносятся в vector<char> и затем копируются из вектора в string:

Функция получает указатель на массив, содержащий не более arraySize символов, и записывает в него данные. Возвращаемое количество записанных чисел заведомо не превышает maxNumChars