CODEWITHSUNDEEP
c++cwindowswinapiunicode
c z
c z

Reputation: 8977

Is wchar_t useful for the Windows API anymore?

When I #include <windows.h> in C or C++ I am forced to decide the format of characters, where TCHAR either equals char or wchar_t.

I've looked around quite a bit and as far as posts such as this one or sites like this point out the wchar_t thing came about a long time ago before UTF8 and, for a variety of reasons, isn't a particularly good Unicode solution in modern programming. However these say nothing about support in existing systems already running in wchar_t.

So my question is, which one should I use? If I use plain old char will this be abandoned by MS in the future, since at the end of the day, the wchar_t version of the API is more recent? Or if I use wchar_t, will it be a pain to get my code running on other modern platforms, which developed later using plain old char in UTF8?

Upvotes: 2

Views: 2752

Answers (1)

Tam&#225;s Szelei
Tam&#225;s Szelei

Reputation: 23941

It is definitely useful and the only way to correctly handle arbitrary path names (since they are allowed to contain wide characters). The choice of UTF-16 is often criticized (with a good reason), but that's irrelevant. The OS uses it, so you have to use it, too. The best you can do is to always call the wide character version of WINAPI functions (e.g. OpenFileW) and use UTF-8 in your program internally. Yes, that means converting back-and-forth, but that usually isn't a performance bottleneck.

I strongly recommend the UTF-8 Manifesto which explains why objectively this is the best way to go.

Portability, cross-platform interoperability and simplicity are more important than interoperability with existing platform APIs. So, the best approach is to use UTF-8 narrow strings everywhere and convert them back and forth when using platform APIs that don’t support UTF-8 and accept wide strings (e.g. Windows API). Performance is seldom an issue of any relevance when dealing with string-accepting system APIs (e.g. UI code and file system APIs), and there is a great advantage to using the same encoding everywhere else in the application, so we see no sufficient reason to do otherwise.

Upvotes: 8

Related Questions