Re:Why C++ Sails When the Vasa Sank [pdf]
by humanrebar on Tuesday June 24, 2014 @10:58AM
(#7938103)
The problem with string classes, including std::string, is that they are object oriented. The things you do with a string should be orthogonal to how the string works. When you think about it std::string is really a string buffer. And if we had good string algorithms, it wouldn't be much more useful than vector<char>.
In various circumstances you may want: string_views, copy_on_write_buffers, small_buffers (for small-string optimization), native arrays of chars, std::arrays of chars, std::vectors of chars, tries, and so on.
In all of the above cases, you should be able to write: auto firstSpace = std::find( begin(myCharContainer), end(myCharContainer), ' '); ...to get an iterator to the first space in your container.
And on top of all that, you could make versions of begin() and end() that return iterators that respect various character encodings.
I, thankfully, haven't used C++ much in the past few years after using it nearly exclusively for about a decade, but the one thing about working in it that will always stick with me is how virtually every project would eventually have like 8 different string classes contained within it for much the same reason (different libraries and/or OS level APIs would use different string classes, often their own), and this is well after std::string/wstring were a thing.
That's the real danger with a sprawling language like C++, IMO. Not that you have to use every bit of it in your own code (in your own code you can get by with a very small subset), but the fact that because there's little true consensus on which bits of it to use it, projects with external dependencies (that are also in C++) generally grow to use not only the entire language and standard library in different places, but also a bunch of badly hacked up reimplementations of the standard library that come along with some of those dependencies.