_>поведение может изменится и c_str будет создавать временную копию (например, если строка хранится по
_>кусочкам, или используется пул строк).
А вы знаете хоть одну реализацию, которая так делает?
Действительно, просто интересно поглядеть на такую реализацию.

Я пользовался BC5.0,BC6.0,VC6,VC7,gcc2x,gcc3x ни одна из этих реализаций
такого не делает.

Mazay wrote:
> C>Нет тут копирования во всех реализациях STL которые я знаю. С чего оно
> C>должно появится?
> А если внутренний буфер не одним куском выделен?
Ни разу такого не видел. В следующий Стандарт, кстати, добавят пункт о
том, что строка должна располагаться непрерывно в памяти.

Копирование в c_str может произойти если требуется добавить в строку
завершающий 0. Например, const_string от Максима Егорушкина позволяет
делать такое:

//В этой строчке, кстати, не происходит динамического
//распределения памяти - в строку записывается ссылка
//на константную строку.
const_string<char> str(boost::cref("Hello, world!"));
//В another попадает ссылка на родительскую строку и
//позиция подстроки. Копирования нет.
const_string<char> another=str.substr(1,2);
//О нет! Нужен завершающий '0'! Происходит копирование
//подстроки и добавление конечного нуля.
printf(another.c_str());

> Doc выше написал что выделенный буфер может умереть.
Нет. Он может умереть в случае вызова неконстантного метода.

> Так что надо сразу копировать строку в "вечный" буфер.
Зачем?

Здравствуйте, Cyberax, Вы писали:

>> А если внутренний буфер не одним куском выделен?
C>Ни разу такого не видел. В следующий Стандарт, кстати, добавят пункт о
C>том, что строка должна располагаться непрерывно в памяти.
Значит и Комитет признаёт, что отсутствие такого требования — ошибка.

>> Doc выше написал что выделенный буфер может умереть.
C>Нет. Он может умереть в случае вызова неконстантного метода.
Вот именно. ИМХО на практике это означает "когда угодно", поскольку существует туча случаев, когда вызов неконстантного метода можэно незаметить.

>> Так что надо сразу копировать строку в "вечный" буфер.
C>Зачем?
Затем, что буфер, возвращаемый c_str(), использовать опасно, ибо он может быть неявно совобожлён при вызове неконстантного метода строки.

Здравствуйте, Smal, Вы писали:

S>Здравствуйте, Aera, Вы писали:

A>>Строки не входят в STL, STL — это только контейнеры и алгоритмы.

S>Где это написано, что string не входит в STL?

Лень искать серьезный источник. Можно посмотреть здесть Стандартная_библиотека_шаблонов

Здравствуйте, Smal, Вы писали:

A>>Строки не входят в STL, STL — это только контейнеры и алгоритмы.

S>Где это написано, что string не входит в STL?

А где написано, что входит?

Здравствуйте, kan_izh, Вы писали:

>> И это НЕ хороший тон, когда результат c_str() копируется куда-то ещё.
>> Нужно пользоваться тем что он валиден, до вызова неконстантной функции.
_>Это да. На самом деле c_str() сделан лишь для совместимости с С-style строками, и им пользоваться нужно по минимуму.

Хорошо, как тогда следует объявлять, скажем, параметры функции? foo(std::string const &)? Тогда CString, AnsiString, BicycleString и т. п. в пролете, здесь уже гарантированно лишнее копирование. Я еще могу согласиться с template <class It> R foo(It first, It last), но и этот вариант имеет проблемы: реализация обязательно в header'е, да и пресловутое code bloat.

Здравствуйте, Mazay, Вы писали:

C>>Нет. Он может умереть в случае вызова неконстантного метода.
M>Вот именно. ИМХО на практике это означает "когда угодно", поскольку существует туча случаев, когда вызов неконстантного метода можэно незаметить.

Я фигею, дорогая редакция.
А как иначе ещё может вести себя std::string? Это ведь не класс-шаман, который знает обо всём, что творится в программе. Откуда ему знать, что там дальше программма будет делать с const char*?
Это то же самое, что недоумевать по поводу голого char* : я передал указатель другому экземпляру класса, сам позже поменял значение по это указателю и, в итоге, тот класс, которому я передал указатель по значению содержит уже другую информацию, а не ту, что я хотел.

Здравствуйте, Шебеко Евгений, Вы писали:

ШЕ>P.S. А вообще кто-нибудь видел вживую реализацию std::string и std::vector которые хранили бы данные не сплошным массивом?
ШЕ>Откуда такие мысли?

Что касается std::vector, то последовательное хранение элементов гарантируется Стандартом.
А вот относительно std::string такой гарантии нет, оттуда и мысли. На мой взгляд, вполне разумные, т.к. использование особенностей реализации может сослужить плохую службу в будущем.

Здравствуйте, Mazay, Вы писали:

M>Я от такого кода чешусь — физически такой penalty не могу переварить. Я ж потом два дня буду больным ходить,если такое придётся написать. Подумать только — ради использования библиотеки — гонять целые строки по памяти. Но самое главное что этим дело скорей всего не закончится и где то будет код типа:

A>>

A>>  some.SetText(text.c_str());
A>>

Пользуйся CString из MFC и будет тебе счастье

Здравствуйте, Aera, Вы писали:

A>Лень искать серьезный источник. Можно посмотреть здесть Стандартная_библиотека_шаблонов

Не надо искать серьезный источник, источник в таких вопросах может быть только один -- Стандарт.


ISO/IEC
14882 :

The C + + Standard Library provides an extensible framework, and contains components for: language support,
diagnostics, general utilities, strings, locales, containers, iterators, algorithms, numerics, and
input/output. The language support components are required by certain parts of the C + + language, such as
memory allocation (5.3.4, 5.3.5) and exception processing (clause 15).

Здравствуйте, Roman Odaisky, Вы писали:

S>>Где это написано, что string не входит в STL?

RO>А где написано, что входит?

В стандарте.

Здравствуйте, Nose, Вы писали:

N>Здравствуйте, Roman Odaisky, Вы писали:

S>>>Где это написано, что string не входит в STL?

RO>>А где написано, что входит?

N>В стандарте.

В стандарт входят только семь контейнеров: vector, deque, list, set, multiset, map, multimap.
string не входит.

Здравствуйте, KBH, Вы писали:

KBH>В стандарт входят только семь контейнеров: vector, deque, list, set, multiset, map, multimap.
KBH>string не входит.

Пардон, в STL, а не в стандарт.

Здравствуйте, Nose, Вы писали:

N>Здравствуйте, Aera, Вы писали:

A>>Лень искать серьезный источник. Можно посмотреть здесть Стандартная_библиотека_шаблонов

N>Не надо искать серьезный источник, источник в таких вопросах может быть только один -- Стандарт.

N>ISO/IEC
N>14882 :

N>The C + + Standard Library provides an extensible framework, and contains components for: language support,

Стандарт описывает стандартную библиотеку, а STL — "стандартная библиотека шаблонов", это нечто совсем другое. STL в стандарте вообще не упоминается, поскольку это историческое название библиотеки контейнеров и алгоритмов. Строки и потоки ввода вывода входят в стандартную библиотеку, но не входят в STL.

Здравствуйте, Nose, Вы писали:

N>ISO/IEC
N>14882 :

N>The C + + Standard Library provides an extensible framework, and contains components for: language support,
N>diagnostics, general utilities, strings, locales, containers, iterators, algorithms, numerics, and
N>input/output. The language support components are required by certain parts of the C + + language, such as
N>memory allocation (5.3.4, 5.3.5) and exception processing (clause 15).

Не путай C++ Standard Library и Standard Template Library.

— std::string входит в C++ Standard Library

— Standard Template Library входит в C++ Standard Library

— std::string не входит в Standard Template Library

Здравствуйте, KBH, Вы писали:

KBH>Здравствуйте, KBH, Вы писали:

KBH>>В стандарт входят только семь контейнеров: vector, deque, list, set, multiset, map, multimap.
KBH>>string не входит.

KBH>Пардон, в STL, а не в стандарт.

Угу, разобрался... Это у меня смешение понятий произошло — C++ Standard Library и STL

Здравствуйте, Nose, Вы писали:

N>The C + + Standard Library provides an extensible framework, and contains components for: language support,
N>diagnostics, general utilities, strings, locales, containers, iterators, algorithms, numerics, and
N>input/output. The language support components are required by certain parts of the C + + language, such as
N>memory allocation (5.3.4, 5.3.5) and exception processing (clause 15).

нда, пардон.
Это у меня смешение понятий произошло — C++ Standard Library и STL

KBH wrote:
> В стандарт входят только семь контейнеров: vector, deque, list, set,
> multiset, map, multimap.
> string не входит.
В Стандарте нет разделения на STL и не-STL.

Смотрим оглавление ISO/IEC 14882:
20. General utilities library
21. Strings library
22. Localization library
23. Containers library
24. Iterators library
25. Algorithms library
26. Numerics library
27. Input/output library

Где тут начинается и кончается STL?

Nose wrote:

> KBH>>В стандарт входят только семь контейнеров: vector, deque, list,
> set, multiset, map, multimap.
> KBH>>string не входит.
> KBH>Пардон, в STL, а не в стандарт.
> Угу, разобрался... Это у меня смешение понятий произошло — C++ Standard
Чуваки буквоедством занимаются, не обращай внимания.

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, Cyberax, Вы писали:

>>> А если внутренний буфер не одним куском выделен?
C>>Ни разу такого не видел. В следующий Стандарт, кстати, добавят пункт о
C>>том, что строка должна располагаться непрерывно в памяти.
M>Значит и Комитет признаёт, что отсутствие такого требования — ошибка.

>>> Doc выше написал что выделенный буфер может умереть.
C>>Нет. Он может умереть в случае вызова неконстантного метода.
M>Вот именно. ИМХО на практике это означает "когда угодно", поскольку существует туча случаев, когда вызов неконстантного метода можэно незаметить.

>>> Так что надо сразу копировать строку в "вечный" буфер.
C>>Зачем?
M>Затем, что буфер, возвращаемый c_str(), использовать опасно, ибо он может быть неявно совобожлён при вызове неконстантного метода строки.

а ты как хотел??? вызвали неконстантный метод -> строка изменилась -> возможная переаллокация памяти -> закономерность невалидности результата предыдущего выщова c_str!