3 ms·

No, it isn't "simply age." I know projects started in 2014 that defined their own string types since there are a lot of things that std::string doesn't support

No, it isn't "simply age." I know projects started in 2014 that defined their own string types since there are a lot of things that std::string doesn't support. For example, you can't turn a C string into a std::string without copying. There is basically no usable unicode support in std::string. Copies of std::string use copy-on-write, which may create hidden race conditions when sharing data between threads. If you want to fix those problems, you need your own string type.

paulddraper 11y ago
How does std::string copy on write cause race conditions?
- reality_czech 11y ago
  Because if you "copy" a string and the copy really is just a reference to some shared data structure, changing the shared data structure later in another thread without memory barriers or other synchronization causes undefined behavior. Remember that the shared data structure will need a reference count to be updated whenever a reference gets deleted.
slavik81 11y ago
Two things to note. std::string is pretty much barred from being CoW as of C++11. QString is CoW, but as of Qt4, cross-thread copies are safe to modify just like normal objects.
nly 11y ago
> you can't turn a C string into a std::string without copying. C and C++ use value semantics by default. std::string is a value., a char* is a reference, so this shouldn't be surprising. If you want an immutable, zero-copy, drop-in replacement for std::string, use boost::string_ref (a variant of which will soon be standard). It'll give you a memory unsafe (just like a char\) reference to a C string or* a std::string. Want to wrap a C string safely? Use it in combination with unique_ptr or shared_ptr<char> (for exception safety). > Copies of std::string use copy-on-write, Actually that's explicitly forbidden by the standard, since C++11. The interface for std::string always assumed mutation, which made COW really inefficient. > which may create hidden race conditions when sharing data between threads The COW versions of std::string, that I'm aware of at least, were always thread-safe.
- reality_czech 11y ago
  Thank you for the correction about std::string no longer being copy-on-write. I'm glad they changed this in C++11. string_ref also sounds like a step in the right direction, assuming it is well-implemented.

paulddraper 11y ago

How does std::string copy on write cause race conditions?

reality_czech 11y ago
Because if you "copy" a string and the copy really is just a reference to some shared data structure, changing the shared data structure later in another thread without memory barriers or other synchronization causes undefined behavior. Remember that the shared data structure will need a reference count to be updated whenever a reference gets deleted.

slavik81 11y ago

Two things to note. std::string is pretty much barred from being CoW as of C++11. QString is CoW, but as of Qt4, cross-thread copies are safe to modify just like normal objects.

nly 11y ago

> you can't turn a C string into a std::string without copying. C and C++ use value semantics by default. std::string is a value., a char* is a reference, so this shouldn't be surprising. If you want an immutable, zero-copy, drop-in replacement for std::string, use boost::string_ref (a variant of which will soon be standard). It'll give you a memory unsafe (just like a char\) reference to a C string or* a std::string. Want to wrap a C string safely? Use it in combination with unique_ptr or shared_ptr<char> (for exception safety). > Copies of std::string use copy-on-write, Actually that's explicitly forbidden by the standard, since C++11. The interface for std::string always assumed mutation, which made COW really inefficient. > which may create hidden race conditions when sharing data between threads The COW versions of std::string, that I'm aware of at least, were always thread-safe.

reality_czech 11y ago
Thank you for the correction about std::string no longer being copy-on-write. I'm glad they changed this in C++11. string_ref also sounds like a step in the right direction, assuming it is well-implemented.