станд.:: строка в многопоточной программе

Вы правы. Это будет исправлено в C ++ 0x. Пока вы должны полагаться на документацию по вашей реализации. Например, последние версии libstdc ++ (GCC) позволяют использовать строковые объекты как если бы ни один строковый объект не разделяет свой буфер с другим. C ++ 0x заставляет реализацию библиотеки защищать пользователя от «скрытого совместного использования».

Я регулирую доступ к строке:

• make std :: string члены частные
• return const std :: string & для геттеров
• установщики модифицируют член

Это всегда хорошо работало для меня и является правильным сокрытием данных.

Если вы хотите отключить семантику COW, вы можете заставить свои строки делать копии:

// instead of:
string newString = oldString;

// do this:
string newString = oldString.c_str();

Как уже указывалось, особенно если вы могли бы иметь встроенные нули, вам следует использовать итератор ctor:

string newString(oldString.begin(), oldString.end());

Вы не можете безопасно и переносимо делать что-либо в многопоточной программе. Не существует такой вещи, как переносимая многопоточная программа на C ++, именно потому, что потоки выкидывают все, что C ++ говорит о порядке операций и результатах изменения любой переменной, за пределы окна.

Также нет ничего в стандарте, чтобы гарантировать, что вектор можно использовать так, как вы говорите. Было бы законно предоставить реализацию C ++ с расширением потоковой передачи, в котором, скажем, любое использование вектора вне потока, в котором он был инициализирован, приводит к неопределенному поведению. В тот момент, когда вы запускаете второй поток, вы больше не используете стандартный C ++, и вы должны обратиться к поставщику компилятора, чтобы узнать, что безопасно, а что нет.

Если ваш поставщик предоставляет расширение потоков, а также предоставляет std :: строка с COW, которую (следовательно) нельзя сделать потокобезопасной, тогда я думаю, что пока ваш аргумент связан с вашим поставщиком или с расширением потоковой передачи, а не со стандартом C ++. Например, возможно, POSIX должен был запретить строки COW в программах, использующих pthreads.

Вы могли бы сделать его безопасным, имея один мьютекс, который вы используете при любой мутации строки, и любые чтения строки, которая является результатом копии. Но вы, вероятно, получите сокрушительную конкуренцию на этом мьютексе.

который вы выполняете при любой мутации строки и при любом чтении строки, которая является результатом копирования. Но вы, вероятно, получите сокрушительную конкуренцию на этом мьютексе.

который вы выполняете при любой мутации строки и при любом чтении строки, которая является результатом копирования. Но вы, вероятно, получите сокрушительную конкуренцию на этом мьютексе.

You can use STLport. It provides non-COW strings. And it has the same behavior on different platforms.

This article presents comparison of STL strings with copy-on-write and noncopy- on-write argorithms, based on STLport strings, ropes and GNU libstdc++

В компании, в которой я работаю, у меня есть некоторый опыт работы с тем же серверным приложением, созданным с помощью STLport, и без STLport на HP-UX 11.31. Приложение было скомпилировано с помощью gcc 4.3.1 с уровнем оптимизации O2. Поэтому, когда я запускаю программу, созданную с помощью STLport, она обрабатывает запросы на 25% быстрее по сравнению с той же программой, созданной без STLport (которая использует собственную библиотеку STL gcc).

Я профилировал обе версии и обнаружил, что версия без STLport проводит гораздо больше времени в pthread_mutex_unlock () (2,5%) по сравнению с версией с STLport (1%). А сам pthread_mutex_unlock () в версии без STLport вызывается из одной из функций std :: string.

Однако, когда после профилирования я изменил назначения строк в наиболее часто вызываемых функциях таким образом:

In MSVC, std::string is no longer reference counted shared pointer to a container. They choose to the entire contents by-value in every copy constructor and assignment operator, to avoid multithreading problems.

Более правильным вариантом было бы "Вы не можете безопасно и портативно использовать С++ в многопоточной среде". Нет никакой гарантии, что и другие структуры данных будут вести себя разумно. Или что время выполнения не взорвет ваш компьютер. Стандарт не гарантирует ничего о потоках.

Поэтому, чтобы сделать что-либо с потоками в Си++, нужно полагаться на реализационные гарантии. И тогда можно смело использовать std::string, так как каждая реализация говорит о том, безопасно ли использовать ее в потоковом окружении или нет.

Вы потеряли всякую надежду на истинную переносимость в тот момент, когда породили второй поток. std::string не "менее переносимый", чем остальной язык/библиотеку.

.