11

As I understand it, Windows #defines TCHAR as the correct character type for your application based on the build - so it is wchar_t in UNICODE builds and char otherwise.

Because of this I wondered if std::basic_string<TCHAR> would be preferable to std::wstring, since the first would theoretically match the character type of the application, whereas the second would always be wide.

So my question is essentially: Would std::basic_string<TCHAR> be preferable to std::wstring on Windows? And, would there be any caveats (i.e. unexpected behavior or side effects) to using std::basic_string<TCHAR>? Or, should I just use std::wstring on Windows and forget about it?

Matt Ryan
  • 261
  • 2
  • 10

3 Answers3

17

I believe the time when it was advisable to release non-unicode versions of your application (to support Win95, or to save a KB or two) is long past: nowadays the underlying Windows system you'll support are going to be unicode-based (so using char-based system interfaces will actually complicate the code by interposing a shim layer from the library) and it's doubtful whether you'd save any space at all. Go std::wstring, young man!-)

Alex Martelli
  • 854,459
  • 170
  • 1,222
  • 1,395
  • +1 because the raw reason: On Windows, Unicode goes through wchar_t. Using char for characters on a windows-only code is beyond dumbness. I know. I work with a VERY LARGE application using char with codepages and with localized strings for 10 languages... Eew... – paercebal Dec 27 '09 at 12:15
  • +1 Preach on! I used to take so much heat for this opinion that it's wonderful to hear someone else think the same way. – Frank Krueger Dec 27 '09 at 17:21
10

I have done this on very large projects and it works great:

namespace std
{
#ifdef _UNICODE
    typedef wstring tstring;
#else
    typedef string tstring;
#endif
}

You can use wstring everywhere instead though if you'd like, if you do not need to ever compile using a multi-byte character string. I don't think you need to ever support multi byte character strings though in any modern application.

Note: The std namespace is supposed to be off limits, but I have not had any problems with the above method for several years.

Brian R. Bondy
  • 339,232
  • 124
  • 596
  • 636
  • 2
    Likewise, although I possibly didn't put it in the std namespace at the time. – Matt K Jun 05 '09 at 15:41
  • Technically, it is not legal to add it to the std namespace. :) I doubt many compilers will actually complain about it, but the std namespace is technically off limits. The only thing you're allowed to add to it is specializations of existing templates. – jalf Jun 05 '09 at 18:21
  • MSVC does not complain about a couple of things it should. Namely the use (or lack of) of the typename keyword. – Martin York Jun 05 '09 at 19:47
  • 1
    +1. I use a similar construct to produce Unicode-enabled code that will work both on Windows (`wchar_t`) and Linux (`char`). I understand the std namespace is off-limits, and thus, agree to pay the price if my own `std::tstring` is the cause of problems in my code. I have yet to see a problem. Now, for the current question, I would advise, for Windows-only code, to keep using `std::wstring`. – paercebal Dec 27 '09 at 12:12
  • 3
    Uhm, why not just do `typedef std::basic_string tstring`? – kfsone Jul 30 '13 at 05:29
3

One thing to keep in mind. If you decide to use std::wstring all the way in your program, you might still need to use std::string if you are communicating with other systems using UTF8.

rtn
  • 127,556
  • 20
  • 111
  • 121