17

Which is your favorite way to go with strings in C++? A C-style array of chars? Or wchar_t? CString, std::basic_string, std::string, BSTR or CComBSTR?

Certainly each of these has its own area of application, but anyway, which is your favorite and why?

C. K. Young
  • 219,335
  • 46
  • 382
  • 435
Ra.
  • 2,499
  • 3
  • 28
  • 41
  • Please read the FAQ http://stackoverflow.com/faq Ra. This is a great example of an open-ended question that requires lots of discussion. Downvoted. – Onorio Catenacci Sep 25 '08 at 13:44
  • 1
    I disagree with Onorio - it's a great question for someone that does not know which string system to use among all the choices. Upvoted to cancel Onorio's downvote :) – Greg Whitfield Sep 25 '08 at 15:43
  • You should specify if you are looking for a multiplatform solution or only Windows specific one. This is very important. – sorin Jan 10 '10 at 17:08
  • As std::string is a typedef for std::basic_string, allocator > this question is poorly constructed. – Ricky65 Oct 16 '11 at 01:16

15 Answers15

32

std::string or std::wstring, depending on your needs. Why?

  • They're standard
  • They're portable
  • They can handle I18N
  • They have performance guarantees (as per the standard)
  • Protected against buffer overflows and similar attacks
  • Are easily converted to other types as needed
  • Are nicely templated, giving you a wide variety of options while reducing code bloat and improving performance. Really. Compilers that can't handle templates are long gone now.

A C-style array of chars is just asking for trouble. You'll still need to deal with them on occasion (and that's what std::string.c_str() is for), but, honestly -- one of the biggest dangers in C is programmers doing Bad Things with char* and winding up with buffer overflows. Just don't do it.

An array of wchar__t is the same thing, just bigger.

CString, BSTR, and CComBSTR are not standard and not portable. Avoid them unless absolutely forced. Optimally, just convert a std::string/std::wstring to them when needed, which shouldn't be very expensive.

Note that std::string is just a child of std::basic_string, but you're still better off using std::string unless you have a really good reason not to. Really Good. Let the compiler take care of the optimization in this situation.

Zathrus
  • 9,948
  • 2
  • 25
  • 22
  • If stack overflows is what you want to avoid, then don't store your C-style char arrays on the stack. Store them on the heap. There; problem solved. Unless you meant buffer overflows. – tzot Sep 25 '08 at 23:26
  • What does 'a child of' mean here? – fizzer Nov 19 '08 at 22:22
  • 1
    Remember that different std::string implementations may not be compatible, so you should never use them in binary interfaces like DLLs. – Vincent Robert Nov 19 '08 at 22:53
  • 'a child of' should mean 'typedef basic_string string;' according to cplusplus.com/reference/string/string – Nate Parsons Dec 28 '08 at 05:24
8

std::string !!

There's a reason why they call it a "Standard".

basic_string is an implementation detail and should be ignored.

BSTR & CComBSTR only for interOp with COM, and only for the moment of interop.

James Curran
  • 101,701
  • 37
  • 181
  • 258
6

std::string unless I need to call an API that specifically takes one of the others that you listed.

Lou Franco
  • 87,846
  • 14
  • 132
  • 192
5

Here's an article comparing the most common kinds of strings in C++ and how to convert between them. Unraveling Strings in Visual C++

John D. Cook
  • 29,517
  • 10
  • 67
  • 94
4

If you can use MFC, use CString. Otherwise use std::string. Plus, std::string works on any platform that supports standard C++.

Robert Wilkinson
  • 1,199
  • 1
  • 13
  • 23
  • Actually, embedded compilers may omit the header and still be standards-compliant. – Konrad Rudolph Sep 25 '08 at 13:47
  • I would only recommend MFC if you're forced to use it. It's horrid, and on top of that, it's a Framework with a mound of demands than an application writer will have to meet. It's just not on the right side of the cost/benefit ratio. – Ben Collins Sep 25 '08 at 14:15
  • 1
    MFC can be quite a pain sometimes, but the CString class is not that bad really. You also don't need to include the whole of MFC to use it. It's available in – QBziZ Sep 25 '08 at 15:09
3

When I have a choice (I usually don't), I tend to use std::string with UTF-8 encoding (and the help of UTF8 CPP library. Not that I like std::string that much, but at least it is standard and portable.

Unfortunatelly, in almost all real-life projects I've worked on, there have been internal string classes - most of them actually better than std::string, but still...

Nemanja Trifunovic
  • 24,346
  • 3
  • 50
  • 88
3

I am a Qt dev, so of course I tend to use QString whenever possible :).

It's quite nice: unicode compliant, thread-safe implicit-sharing (aka copy-on-write), and it comes with an API designed to solve practical real-world problems (split, join, replace (with and without regex), conversion to/from numbers...)

If I can't use QString, then std::wstring. If you are stuck with C, I recommend glib GString.

Aurélien Gâteau
  • 4,010
  • 3
  • 25
  • 30
2

C-style char arrays have their place, but if you use them extensively you are asking to waste time debugging off by one errors. We have our own string class tailored for use in our (embedded development environment).

We don't use std::string because it isn't always available for us.

Airsource Ltd
  • 32,379
  • 13
  • 71
  • 75
2

I use std::string (or basic_string<TCHAR>) whenever I can. It's quite versatile (just like CStringT), it's type-safe (unlike printf), and it's available on every platform.

xtofl
  • 40,723
  • 12
  • 105
  • 192
2

Other, std::wstring.

std::string is 20th century technology. Use Unicode, and sell to 6 billion people instead of 300 milion.

MSalters
  • 173,980
  • 10
  • 155
  • 350
2

If you're using MFC, use CString. Otherwise I agree with most of the others, std::string or std::wstring all the way.

Microsoft could have done the world a huge favor by adding std::basic_string<TCHAR> overloads in their latest update of MFC.

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
1

I like to use TCHAR which is a define for wchar or char according to the projects settings. It's defined in tchar.h where you can find all of the related definitions for functions and types you need.

Dror Helper
  • 30,292
  • 15
  • 80
  • 129
1

std::string and std::wstring if I can, and something else if I have to.

They may not be perfect, but they are well tested, well understood, and very versatile. They play nicely with the rest of the standard library which is also a huge bonus.

Also worth mentioning, stringstreams.

luke
  • 36,103
  • 8
  • 58
  • 81
1

Unicode is the future. Do not use char* and std::string. Please ) I am tired of localization bugs.

Ferruccio
  • 98,941
  • 38
  • 226
  • 299
Naishin
  • 21
  • 3
  • 3
    It is perfectly possible to hold Unicode strings in std::string. Just encode them as UTF-8. In fact it is often much better solution than using wstring if you are targeting different operating systems. – Nemanja Trifunovic Sep 25 '08 at 14:10
  • 1
    Yeah, but this is only good for storing. You need to roll your own methods for character-based operations instead of `char`-based ones. – Rafał Dowgird Mar 04 '10 at 14:04
1

std::string is better than nothing, but it's annoying that it's missing basic functionality like split, join and even a decent format call...

dicroce
  • 45,396
  • 28
  • 101
  • 140