[cfe-dev] Extra #defines for Windows SDK 6.0a/VS2008

[Per Lindén]

The sad thing is that socket and thread support needed by libc++ 
indirectly cause inclusion of <windows.h>, at least as far as I can see 
right now. Might be worked around by creating custom declarations of the 
stuff needed but it usually spans 50 files... Also, all C99 standard lib 
stuff must be replicated somehow. Et cetera... (does anyone feel 
responsible for http://wiki.llvm.org/WinC99CLib:Windows_C99_clib ?)

There are of course other problems than MS extensions in the SDK 
headers, such as template abuse, redefinition of "__null" etc. The 
extension stuff implemented in clang so far works fairly well, with the 
exception of some "throw(...)" exception specifications I am 
investigating. In short <windows.h> really sucks, but finding 
non-trivial Windows code that does not pull it in is hard. The question 
is how to solve it without becoming incompatible, violating copyrights 
etc. I volunteer to test and implement different solutions whenever I 
get the time.

Thank you all for engaging in such a hopeless platform.
-- 
Per Lindén

Jesse Towner skrev 2010-08-06 14:04:
> Sorry, I missed what you originally wrote where you implied that you
> couldn't get a translation unit including Windows.h to even compile.
> Yeah, that's definitely a problem. I was thinking more along the lines
> of having Windows.h included by the libc++ headers, which might not be
> the wisest thing to force on the users of a standard library
> implementation.
>
> As far as how other compilers solve it, Intel C++ mimics MSVC++ to the
> extent that it defines _MSC_VER and supports the same compiler
> extensions, and library writers are accustomed to checking for
> __INTEL_COMPILER/ICL before _MSC_VER to differentiate between the two
> compilers. That way it acts as a drop-in replacement for MSVC++. Borland
> C++ came with it's own copy of the Platform SDK headers. And you
> probably know that Cygwin and MinGW also both come with their own copies
> of the headers. So the question is which route should Clang take here?
>
> - Jesse Towner
>
> On Fri, 2010-08-06 at 10:16 +0200, per at lumai.se wrote:
>    
>> Of course there are numerous workarounds. My primary goal is to make it
>> easier to use clang on existing (Windows) code bases. It should "just
>> work" as far as possible. Otherwise, what's the point of
>> TargetInfo::getTargetDefines?
>>
>> Any comments on the actual patch? Perhaps I should file a bug instead?
>>
>>      
>