What C++ string classes/systems exist that have good unicode support and a decent interface?

Question

Using strings in C++ development is always a bit more complicated than in languages like Java or scripting languages. I think some of the complexity comes from a performance focus in C++ and some is just historical.

I know of the following major string systems and would like to find out if there are others and what specific drawbacks they have vs. each other:

• ICU : http://userguide.icu-project.org/strings#TOC-Using-Unicode-Strings-in-C-
• GLib::ustring : http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-basics-ustring.html.en
• MFC CString : http://msdn.microsoft.com/en-us/library/5bzxfsea%28VS.100%29.aspx
• std::basic_string : http://en.cppreference.com/w/cpp/string/basic_string
• QT QString : http://doc.qt.nokia.com/4.6/qstring.html#details

I'll admit that there can be no definite answer, but I think SOs voting system in uniquely suited to show the preferences (and thus the validity of arguments) of people actually using a certain string system.

---

Added from answers:

• UFT8-CPP : http://utfcpp.sourceforge.net/

Answer 1

You should have a look at UTF8-CPP: UTF-8 with C++ in a Portable Way

It is very lean and has a really neat C++ interface, using the standard std::string as container for the string data, thus avoiding lots of casts for other-than-unicode operations, and providing simple additional functions for unicode handling.

Answer 2

Using strings in C++ development is always a bit more complicated than in languages like Java or scripting languages. I think some of the complexity comes from a performance focus in C++ and some is just historical.

I'd say it's all historical. In particular, two pieces of history:

• C was developed back in the days when everyone (even Japan) was using a 7-bit or 8-bit character encoding. Because of this, the concepts of char and "byte" are hopelessly confounded.
• C++ programmers quickly recognized the desirability of having a string class rather than just raw char*. Unfortunately, they had to wait 15 years for one to be officially standardized. In the meantime, people wrote their own string classes that we're still stuck with today.

Anyhow, I've used two of the classes you mentioned:

MFC CString

MSDN documentation

There are actually two CString classes: CStringA uses char with "ANSI" encoding, and CStringW uses wchar_t with UTF-16 encoding. CString is a typedef of one of them depending on a preprocessor macro. (Lots of things in Windows come in "ANSI" and "Unicode" versions.)

You could use UTF-8 for the char-based version, but this has the problem that Microsoft refuses to support "UTF-8" as an ANSI code page. Thus, functions like Trim(const char* pszTargets), which depend on being able to recognize character boundaries, won't work correctly if you use them with non-ASCII characters.

Since UTF-16 is natively supported, you'll probably prefer the wchar_t-based version.

Both CString classes have a fairly convenient interface, including a printf-like Format function. Plus the ability to pass CString objects to this varags function, due to the way the class is implemented.

The main disadvantages are:

• Slow performance for very large strings. (Last I checked, anyway.)
• Lack of integration with the C++ standard library. No iterators, not even << and >> for streams.
• It's Windows-only.

(That last point has caused me much frustration since I got put in charge of porting our code to Linux. Our company wrote our own string class that's a clone of CString but cross-platform.)

std::basic_string

The good thing about basic_string is that it's the standard.

The bad thing about it is that it doesn't have Unicode support. OTOH, it doesn't actively not support Unicode, as it lacks member functions like upper() / lower() that would depend on the character encoding. In that sense, it's really more of a "dynamic array of code units" than a "string".

There are libraries that let you use std::string with UTF-8, such as the above-mentioned UTF8-CPP and some of the functions in the Poco library.

For which size characters to use, see std::wstring vs std::string.

Answer 3

Some random thoughts:

• std::basic_string: No unicode support at all, not really usable for platform-independent applications. If your code is intended for a specific platform, you can usually use std::wstring (Windows, UTF-16) or std::string (Unix-like systems, UTF-8) for storing Unicode strings, but everything else (encodings, character properties, Unicode algorithms...) is completely absent.
• ICU: Idiosyncratic interface that doesn't blend well with STL algorithms (e.g., a Java-style iterator). Apart from that, ICU seems to be an industry standard and is quite extensive. Uses UTF-16 mainly, but supports other encodings.
• Qt: Nice interface that is both practical and STL compatible. Uses UTF-16 internally. Would probably be my first choice if I had to write platform-independent applications in C++.
• GLib, MFC: Don't know about those.
• Platform-dependent facilities: For very basic tasks (e.g., encodings), you can get along with these (e.g. iconv on Unix-like systems, MultiByteToWideChar on Windows). Pro: No external library required.