Hi,
Libraries that produce needless copies are simply ill-designed, and thus it is true great parts of the standard library are),
[...] I'd say there's something a bit more fundamental going on here than _just_ a library design issue :-) No class can be all things to all users.
This isn't even a design issue. Your standard library is just being stupid (or overly pedantic) in its handling of operator==(string const&, char const*). Let them know how you feel.
Sure, that's certainly a very important factor. But I was going in a bit different direction. I'm of course delighted when people have sat down and produced an elegant and robust class design. I've had the pleasure to use a number of libraries with an excellent design. But each library has a purpose and it may differ from that of the developer. Of the libraries I have come across, the ones that tried to cover the whims of every turkey that walked by often had the most incomprehensible and bug-ridden interfaces and implementations. It's healthy when developers know the purpose of their classes and know when to resist requests for significant deviations. No class can nor needs to be all things to all users. In a way of an example, I happen to find std::string a decent general string class. It has some odd behaviours and maybe flaws, but overall it does a fine job and life is too short to sweat every detail. If I have a huge pool of arbitrary-size read-only strings that I want to treat as highly efficient interned atom database, is std::string a good choice? Nah. If 75% of my strings are dynamically built but read-only after creation, and I want to pass them a lot between threads, is std::string optimal? Naah. If I need to efficiently shuffle a lot of string data over networks, is std::string optimal? Nope. But to pursue any of these into std::string interface? Surely madness lies that way? How about a very general string-like concept which would be able to cover all these bases with suitably clever parametrisation? Why, when each can be satisfied by 50-500 lines of very straightforward code every dabbling developer will understand in hours? On the other hand, there _are_ areas where suitable abstraction pays off _big_ time. Lassi PS. In my earlier example the best choice would have been to drop strings altogether.