[cfe-dev] Windows headers that are troublesome for clang

[James Gregurich]

ok. new topic is being started here...

On Aug 26, 2014, at 5:46 PM, Reid Kleckner <rnk at google.com> wrote:

> Your question isn't actually that clear. What kind of brokenness do you care about? Are you looking for C++ that clang can't parse, or standard library features that behave incompatibly on Windows?  I think you mean the former.
> 
> The answer to that question is complicated. It depends on what you want to parse. I'd say there's several classes of stuff in order of increasing difficulty to parse:
> - Plain C Windows SDK headers: windows.h
> - MSVC C++ STL headers: vector, string
> - Templateless COM headers: DirectX etc
> - Template libraries: ATL, WRL
> 
> The first three classes aren't that hard to parse. When they use standard language features, they are mostly well-formed. The difficulty in parsing them is that they use lots and lots of language extensions. The basic stuff is dllexport and __stdcall, but it gets harder. There are weird IDL attributes involving square brackets, for example.
> 
> The final category is really something all on its own. MSVC's template model is drastically different from ours. You could hypothetically hack these headers in probably 20 or so places to get them to parse with Clang without any compatibility hacks, but you end up fighting an uphill battle. This is the category that native GUI apps tend to have, while batch processing apps like LLVM can get by with the first three sets.

thanks for the response!

I’m aware of difficulties in macro processing. that was mentioned by the boost fellow some time back.


you are adding in a few more. Here is the list as I understand it. Please correct it if I am wrong.

1) problems with template definitions and instantiation
2) calling convention and export/import attributes.
3) IDL support
4) difficulties with macro definition and expansion.


Have any of these been fully or partially addressed yet?


a related question:

as I understand it, if you run clang directly on windows (assuming a win32 host environment verses as posix one (cygwin etc)), it compiles as it does on every other platform but the symbols will be gcc-style…not ms-style. If you run it with the clang-cl wrapper, it uses an alternative preprocessor that matches that of cl.exe. Is that understanding correct? can one detect at compile time what processor he is going to get? Is there a switch to pick the desired preprocessor to override what clang-cl might choose by default?

-James