std::string

This does not make any sense. Neither std::string nor char* is adapted to multithreaded environments in itself, you will need some sort of synchronization or exclusion strategy for either to work anyway.

Some implementations of std::string use Copy-on-write semantics, which can cause problems in multithreaded environments. IIRC, though, these are actually pretty rare, for exactly this reason.

The issue has to do with assignment of a std::string in a multithreaded env.

Unless your compiler's standard library documentation tells you not to, std::string is fine as long as you obey normal reader/writer exclusions.

Quote:

Original post by Sneftel IIRC, though, these are actually pretty rare, for exactly this reason.

For a given value of "rare" anyways. IIRC, MSVC 6's std::string implementation uses COW, as do older versions of Borland C++.

Bah, those don't count as C++ compilers anyways ;-).

That said, the proper alternative to std::string in such a situation would be your own string class (or downloading a replacement standard library - doesn't STLport work on VS6?). While std::string + multithreading = problems in a few ancient compilers I wouldn't be caught dead using anyways, "c style" char*s = problems anywhere, and everywhere if used directly.

What you should use is a suitable synchronization primitive to serialize usage of the resource, instead of blindly hoping things will work.

Quote:

Original post by Zao What you should use is a suitable synchronization primitive to serialize usage of the resource, instead of blindly hoping things will work.

Which would be much better advice if you mentioned how to properly synchronize multiple instances of a string object if they used a COW implementation. Entangled state makes this a less straightforward operation than you imply.