Microsoft has a set of typedefs and macros that depend on the
_UNICODE
and
_MBCS
define. You can control the presence of these defines by tweaking the project settings in your Visual Studio Project. Normally you can write the source once and the compile it with many different text encoding settings if you use fancy type-names like
LPCTSTR
, the
_TEXT()
macro, and functions (sorry - macros) like
_tcslen()
.
LPCTSTR my_ptr = _TEXT("funny thing");
size_t len = _tcslen(my_ptr);
Depending on your project settings the above code may be preprocessed to:
const char* my_ptr = "funny thing";
size_t len = strlen(my_ptr);
or
const wchar_t* my_ptr = L"funny thing";
size_t len = wcslen(my_ptr);
or
whatever else...
What I recommend is supporting utf-16 only or utf-16 + utf-8 mixed and forget about fancy microsoft types and macros if you don't want to waste your time for nothing. Turn your project setting to unicode to ask the preprocessor to preprocess your windows system calls to the 'W' (widechar/utf16) version and handle strings/encoding yourself with utf encodings only (ansi is the past). Current windows versions have NT kernel for more than a decade and WinNT uses utf-16 internally so supporting for example ansi besides the widechar version of winapi functions makes no sense. What I ususually do is using utf8 internally in my program (this helps avoiding for example the 'L' prefix in case of strings and saves memory usage) and convert the strings to utf16 for windows only in case of system calls. With proper string classes you can store string in any (platform dependent) format hiding this under the interface, so you can write a string class that stores the string in utf16 for windows and utf8 for unix systems in the same program if string-using system calls are frequent... utf8 makes it easy to port your app to unix like systems while Microsoft macros just complicate things even if you target windows platform exclusively.