Why in C++11 target -win32, char16_t disappears?

Trying to compile program in C++11 mode that uses char16_t fails when target is -win32. For example, the program tc16.cpp:

int main() {
char16_t c;
return 0;
}

will complete with no errors using the command:

clang -std=c++11 -target i686-pc-mingw32 -fsyntax-only tc16.cpp

but will result in error using the command:

clang -std=c++11 -target i686-pc-win32 -fsyntax-only tc16.cpp

Is this a bug?

Yaron

For whatever reason (probably because MSVC does not define those yet), the char(16|32)_t keywords are not defined in MicrosoftMode. So you have to compile with -fno-ms-compatibility for now.

-Nico

Thanks, this indeed brings back char16_t.

Since char16_t, char32_t are part of C++11 standard, shouldn’t clang provide them when -stc=c++11 is specificed?

Yaron

I have tested Visual C++ 2013RC and indeed it does not define char16_t by default.

However, if any C++ is header is included, including , char16_t does gets defined through yvals.h.

This may be consistent with standards since char16_t is part of C++11 but not C99 (may be part of C11).

So if we wish to exactly emulate VC behaviour clang is OK now but it is inconsistent with the -std=c++11 switch. I’ll see if this can be patched.

Yaron

That is not good since Boost header files expect clang to support char16_t. I can test with -fno-ms-compatibility but does not that defeat clang working Under Windows when Windows SDK header files are involved ?

Most of the things changed in MicrosoftMode seem to affect C++ and aren't that relevant for SDK headers since those are C/COM.
And indeed, I've been using Clang for diagnostics just fine on a COM project. And it seems as if there's no pressing need to have that pesky -fdelayed-template-parsing mode enabled, too. I've found only one issue which can be worked around by forward declaring IUnknown.

-Nico

That is not good since Boost header files expect clang to support
char16_t. I can test with -fno-ms-compatibility but does not that defeat
clang working Under Windows when Windows SDK header files are involved ?

Most of the things changed in MicrosoftMode seem to affect C++ and aren't
that relevant for SDK headers since those are C/COM.

It will affect ATL/WTL a *lot*, but we can't quite parse those yet anyway.