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

да что вы паритесь? главное, что результат c_str ничего не копирует (иначе кто должен это освобождать?) и валиден до следующей модификации строки. А этого времени, я думаю, будет достаточно, чтобы передать raw ptr в (WIN/LINUX)API функции и забыть.

Здравствуйте, Константин Л., Вы писали:

КЛ>ИМХО хорошим тоном считается немедленное копирование raw char* куда-нибудь при получении его через c_str. Иначе его хранение может сильно испортить настроение.

Ну так ведь, знаете, и указатели на элементы вектора тоже не стоит хранить... Потому что при первом же reserve они инвалидируются.
А для строк инвалидирование происходит и при более мягких условиях: при любом факте изменения. И это осмысленно.
Строка — это, в первую очередь, текстовое значение — и только потом контейнер символов. Это касается как std::string, так и CString, и AnsiString, и всяких велосипедов.

КЛ>>ИМХО хорошим тоном считается немедленное копирование raw char* куда-нибудь при получении его через c_str. Иначе его хранение может сильно испортить настроение.

К>Ну так ведь, знаете, и указатели на элементы вектора тоже не стоит хранить... Потому что при первом же reserve они инвалидируются.
К>А для строк инвалидирование происходит и при более мягких условиях: при любом факте изменения. И это осмысленно.
К>Строка — это, в первую очередь, текстовое значение — и только потом контейнер символов.

Такой подход и привел к тому, что std::string невозможно нормально с API использовать... Имхо, строка должна быть _и_ текстом _и_ контейнером, причем довольно специфическим. Наиболее приятно работать, как ни странно, с CString, хотя он спроектирован ну совсем не по "правилам" — ни вам тут итераторов, ни алгоритмов, ни внешних функций, все на индексах. Ан нет, нормально и вполне удобно получается. В общем, мое мнение, что std::string в большинстве практических случаев — анюзабл. Сам по себе — он вполне самодостаточен. Но как только пытаешься его использовать при взаимодействии с апи или другим нативным кодом — все, швах. По-крайней мере, во всех проектах, где участвовал я, std:string либо использовался как временное хранилище для интерфейса с другими библиотеками, либо его не было вообще.

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

К>Здравствуйте, Константин Л., Вы писали:

КЛ>>ИМХО хорошим тоном считается немедленное копирование raw char* куда-нибудь при получении его через c_str. Иначе его хранение может сильно испортить настроение.

К>Ну так ведь, знаете, и указатели на элементы вектора тоже не стоит хранить... Потому что при первом же reserve они инвалидируются.

ну я и не храню.

К>А для строк инвалидирование происходит и при более мягких условиях: при любом факте изменения. И это осмысленно.

exactly

К>Строка — это, в первую очередь, текстовое значение — и только потом контейнер символов. Это касается как std::string, так и CString, и AnsiString, и всяких велосипедов.

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

Роман! А что не так?
Как раз вот такие фокусы в MFCишной строке хорошо обустроены.
И вообще, строка как раз в MFC ИМХО не такая уж и плохая
Во всяком случае в не слишком древнем MFC

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

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

В FAQ

PART II QUESTIONS

1. What is the STL (Standard Template Library)?
A. The STL is a data structures or container class library that has
been adopted into the language. It consists of three major components:
Containers or data structures
Iterators
Algorithms


Containers include such things as vectors, lists, queues, priority
queues, stacks, maps, and sets. In STL, containers (data structures)
are templatized.
...

Ну или скачать её и поискать там string

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

C>В следующий Стандарт, кстати, добавят пункт о том, что строка должна располагаться непрерывно в памяти.


А нет ли ссылочки? А то в драфте (DTR 19768) не нашел