Why is there a different string class in every C++ platform out there?

Question

While I like programming in C++, I hate the idea of:
std::basic_string vs QString vs wxString vs .............
Doesn't the standard string class satisfy the needs for these frameworks? I mean what is wrong with the standard string class?!

Just to emphasize, that below is the important question:
Do you learn "the" string class of the framework in every framework you are going to work with? would you instead stick to the standard string class by trying to adapt it everywhere?

Thanks...

Answer 1

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.

Answer 2

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.

Answer 3

IMO, std::string isn't old enough to be widespread (Qt and wxWidgets are older than the STL, or at least older than widely available stable and working STLs). Also, std::string is sadly not the best string class there is for everyone, and other frameworks have other needs.

C++ STL is very resource optimized, whereas the Qt string class offer lots of goodies that a committe would never agree on, especially as some want it to be easily implementable on embedded systems and the like.

Answer 4

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.

Answer 5

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).

Answer 6

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.

Answer 7

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...