To be fair, maintaining compatibility with existing software (including libc) is the reason, either directly or indirectly, for many (most?) of the gotchas in C++.
Then again "your C code is valid C++ code!" was perhaps the biggest selling point of C++ when it came out.
std::string is a complete replacement for C strings. That is, fixed character width ASCII-or-equivalent strings. That's what it was designed for, and that's what it is.
People often complain about the lack of a real "string class" in the standard C++ library. Well, guess what? No language today really has primitives that handle unicode absolutely perfectly, and there's still intense debate about what they should be doing with respect to encodings, length() functions etc.
Maybe the answer is that Unicode itself should be simplified so that every word in language has one representation in any particular encoding.
A C string could be just as well replaced with a std::vector<char> (or a wide variant thereof) without any significant loss of functionality.
std::string is an embarassement. It's both bloated (why, we need to have both iterator-based and index-based access interfaces!) and lacks basic string manipulation functionality, it's encoding-unaware.
- std::string is old. It predates the rest of the STL, and had an index interface prior to the iterator based one. The old API was left in for compatibility and imposes no runtime overhead
- It has all the string manipulation capability of the C standard library
- Being encoding unaware was probably a blessing given how unicode has evolved since std::string was introduced (20-30 years ago?)
If you want to use std::string operations on an array of characters that you don't own or that are part of an indivisible larger structure, you're out of luck.
It's not difficult to craft a slice-like replacement, but range types will be most welcome when they finally hit the standard.
Then again "your C code is valid C++ code!" was perhaps the biggest selling point of C++ when it came out.