While I like programming in C++, I hate the idea of:
std::basic_string vs
QString vs
wxString vs .............
Doesn\'t the
One reasonable reason (versus unreasonable reasons like "I don't want to learn the Standard Library") is that some libraries wish to retain control over the binary layout, in order to achieve certain kinds of interoperability (such as binary compatibility across versions). An example of this is _bstr_t in the VC++ libraries; it is important for COM purposes that a _bstr_t is represented as a BSTR (since that is what COM needs), so a wrapper built on top of a BSTR is valuable to COM developers.
std::string is great... Oh, except that it doesn't have a "Format()" call... And, it doesn't have Split() or Join()... Actually, it doesn't do a lot of things that users of strings in those "inferior" scripting language get to take for granted...
If C++ had the ability to ADD to existing classes (like Objective-C or Ruby) then you probably wouldn't see this...
Also, consider that C++ generally does a better job (than things like Java) at letting you create objects that behave like real native types...
The reason for multiple string classes is that the C++ standard was finalized fairly late (in 1998); it then took some time until all systems actually provided a correct C++ library. By that time, all these competing string classes where already written.
In addition, in some cases, people want to inherit from a single base class, which std::string wouldn't do.
IIRC Bjarne Stroustrup deliberately omitted a String class from C++ as he considered it a "rite of passage". All those who learnt C++ were expected to write their own. Certainly at the start of C++ there were no standard libraries and I remember versions from AT&T (which was a preprocessor for C) and the NIH Classes from a very pioneering group at the National Institutes of Health in the US (which also included early collection classes).
One of the main problems with std::string
is the lack of Unicode support. Even with std::wstring
you only get a container for Unicode code points, but would still have to implement the Unicode-aware functionality.
Also, QString
for example is "implicitly shared". This makes it very easy to pass strings around your code in an efficient way. They are actually copied only on write.
One of the tenants of C++ is "You don't pay for what you don't need." This means there does not need to be a one-size-fits-all string class that every C++ programmer MUST know and (more importantly) must USE. Maybe your project requires thread-safe strings. You can roll your own class. And you always have the option of using the existing std::string.
It just so happens that in most cases std::string is good enough. But when it isn't, aren't you glad you aren't locked into it. Try to roll your own String class in Java and see how long it takes until you are pulling your hair out.
As for your second point, if you are going to fight against a library you've added to your project, why did you add the library to your project in the first place? Part of the decision to use wxWidgets or QT is the acknowledgment that you must embrace its string class in your project (or at least a sizable portion of that project). Just like the decision to a "C" library means putting up with char* buffers and size parameters on all the functions.
So, yes, learn the alternate string class. If you are using a library (and wish to become proficient with it) you can't decide to ignore part of the library just because "it's another string class". That makes no sense.