Question

It’s been quite some time now that I’ve been coding in C++ and I think most who actually code in C++, would agree that one of the most trickiest decisions is to choose from an almost dizzying number of string types available. I mostly prefer ATL Cstring for its ease of use and features, but would like a comparative study of the available options.
I’ve checked out SO and haven’t found any content which assists one choosing the right string. There are websites which state conversions from one string to another, but thats not what we want here.

Would love to have a comparison based on specialty, performance, portability (Windows, Mac, Linux/Unix, etc), ease of use/features, multi language support(Unicode/MBCS), cons (if any), and any other special cases.

I’m listing out the strings that I’ve encountered so far. I believe, there would be more, so we may edit this later to accommodate other options. Mind you, I’ve worked mostly on Windows, so the list reflects the same:

1. char*
2. std::string
3. STL’s basic_string
4. ATL’s CString
5. MFC’s CString
6. BSTR
7. _bstr_t
8. CComBstr

Answer 1

Don’t mean to put a dampener on your enthusiasm for this, but realistically it’s inefficient to mix a lot of string types in the one project, so the larger the project gets the more inevitably it should settle on std::string (which is a typedef to an instantiation of STL’s basic_string for type char, not a different entity), given that’s the only Standard value-semantic option. char* is ok mainly for fixed sized strings (e.g. string literals, fixed size buffers) or interfacing with C.

Why do I say it’s inefficient? You end up with needless template instantiations for the variety of string arguments (permutations even for multiple arguments). You find yourself calling functions that want to load a result into a string&, then have to call .c_str() on that and construct some other type, doing redundant memory allocation. Even const std::string& requires a string temporary if called using an ASCIIZ char* (e.g. to some other string type’s buffer). When you want to write a function to handle the type of string a particular caller wants to use, you’re pushed towards templates and therefore inline code, longer compile times and recompilation depedencies (there are some ways to mitigate this, but they get complex and to be convenient or automated they tend to require changes to the various string types – e.g. casting operator or member function returning some common interface/proxy object).

Projects may need to use non-Standard string types to interact with libraries they want to use, but you want to minimise that and limit the pervasiveness if possible.