0

I am starting to work on a completely new project for Windows Desktops written in C++. When I learned Windows programming, I read that using TCHAR is a great improvement because I can build an ANSI or a Unicode version of my program without changing the code. However, I never really used the option to build the ANSI version. Moreover, in the standard library of C++, there is no TCHAR, I have to create typedefs for std::string, std::stringstream, etc. and their wide string counterparts. So currently I am thinking of abandoning TCHAR in favor of wchar_t, and I collected the following advantages and disadvantages.

Advantages:

  • TCHAR is a macro, so if I don't use it, the front-end compiler and Intellisense will give better results.
  • It is more explicit what the type of a variable is.
  • L"" is easier to type than _T("").

Disadvantages:

  • Loss of modularity regarding the character type (even though I don't really need the ANSI version, I find using an abstract character type to be a neat feature, and what if in the future I will need a UTF-8 or UTF-32 version?).
  • I would have to postfix some API functions with W, like GetWindowTextW.

And my questions:

  • Is there an easier way in the C++ standard library to use TCHAR than the one I described above? Like a standard header file that has these typedefs?
  • Do you think that my reasoning is correct?
  • Do I miss any important point?
  • What is the state-of-the-art solution today? Do professional Windows programmers still use TCHAR (in new code)?
  • If I remove TCHAR, than should I write L"" or u"" instead of _T("")?
z32a7ul
  • 3,695
  • 3
  • 21
  • 45
  • http://stackoverflow.com/questions/234365/is-tchar-still-relevant – Deduplicator Nov 30 '16 at 11:48
  • Thanks for the link, I found it, too, but my question is a bit different, and anyway I don't think that the answers of 2008 can be automatically accepted as the state-of-the-art solution in 2016. – z32a7ul Nov 30 '16 at 11:51
  • 2
    IMO It is not worth the extra effort, stick to one and convert when appropriate. If TCHAR would be flawlessly implemented it would be another story, but it is not. At our company we stick with std::string and have UTF-8 strings which works fairly well, when we need to deal with Win32 we convert to wchar_t – AndersK Nov 30 '16 at 12:00
  • YAGNI - If Windows were to suddenly support UTF-8 or UTF-32, what are the odd that your TCHAR code would work for that. About zero. And you don't *have* to add a W to the system calls, windows.h is packed with macros doing that for you. – Bo Persson Nov 30 '16 at 12:30
  • 2
    It's an opinion based question, and so should be closed. The answer is, that you should use `TCHAR` if you plan to target Windows 98. If not, then you should use `TCHAR`. The hope that you might get UTF-8 support for free in the future is wishful thinking. Windows will never support UTF-8 through the same A/W mechanism as ANSI and Unicode. – David Heffernan Nov 30 '16 at 12:35
  • For me `TCHAR` looks better and is easier to write than `wchar_t`. About `T("")` agree that `L""` is easier. – i486 Nov 30 '16 at 12:46
  • really this question about - hardcode use `funcA` or `funcW` api or have a possibility by define/undefine `UNICODE` (`_UNICODE`) macro switch from `funcA` to `funcW` or visa versa. how minimum from win200 almost all `funcA` is shell over `funcW` (allocate memory, convert strings (A->W), call `funcW`, convert (W->A), free memory) - so we have big performance penalty here. and how handle not `EN` strings / names ? say as file name or text in edit control. here big problems if we use ANSI. – RbMm Nov 30 '16 at 13:02
  • many ANSI programs print hieroglyphs when try print not `EN` message, got from system. some `funcA` at all have restricted functional compare `funcW` (say CreateFileA limited to MAX_PATH characters). so no sense use `funcA` or TCHAR. always build new app with `UNICODE` – RbMm Nov 30 '16 at 13:02
  • The windows type to hold wide characters is WCHAR , not wchar_t. wchar_t is a c++ type that, on microsoft compilers incidentally is the same size as WCHAR, but if you end up writing any multiplatform code where compilers have a 32bit wchar_t, its important to distinguish between the two. – Chris Becke Nov 30 '16 at 13:51
  • http://utf8everywhere.org/ – Clearer Feb 21 '18 at 07:15

1 Answers1

1

In modern windows all ANSI functions are internally converting char* to wchar_t* and calling unicode versions of same function. Basically, by adopting TCHAR instead of wchar_t you gain nothing, but have to deal with quirky syntax.

Starl1ght
  • 4,422
  • 1
  • 21
  • 49