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

Jesse Towner townerj at gmail.com
Fri Aug 6 09:01:00 PDT 2010


On Fri, 2010-08-06 at 17:05 +0200, Per Lindén wrote:
> 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 ?)

What part of the C++0x Standard Library or libc++ uses sockets? The
Windows API calls for the threads library, and perhaps
std::chrono::monotonic_clock and a few other classes, that you might
want included in header files so that it can be inlined to reduce call
overhead can probably be isolated to a hundred lines of code or less.
And then for the rest for the stuff that is best placed in source files,
including Windows.h isn't an issue.

Many of the C99 functions that are a part of C++0x will probably end up
in the next version of MSVC++'s CRT as it begins to implement more of C
++0x (cstdint is already in MSVC++2010), but it's probably still going
to be missing a lot of C99 functionality that will be needed by Clang in
C99 mode (such as no stdint.h or tgmath.h for example, just cstdint and
ctgmath). Writing the C99 math functions isn't too difficult, a lot of
it is pretty easy, and the transcendental functions just use various
numerical methods or identities with other existing functions. But
getting it to be fully standards compliant would require some rigor and
thorough testing. Plus providing optimized versions for say x86/x86-64
SSE/SSE2+ targets would be more involved. Isn't this stuff already apart
of the MinGW/BSD implementations that the WinC99 library was going to be
using?

> 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.

Yeah, another thing is implementing all of the COM/COM+ extensions too.
Does Clang implement any of this yet?

- Jesse Towner




More information about the cfe-dev mailing list