[cfe-dev] Extra #defines for Windows SDK 6.0a/VS2008
per at lumai.se
per at lumai.se
Sat Aug 7 05:27:10 PDT 2010
On closer inspection, the socket dependency is limited to the socket
error codes in <system_error>, such as ECONNRESET et al. One less
problem. I am initially aiming for a non-math-correct version of libc++
that builds and can replace everyday STL headers, such as <vector>,
<map> etc.
Is this WinC99 lib being worked on by anyone? Never heard of it except
for the wiki entry...
--
Per Lindén
Jesse Towner skrev 2010-08-06 18:01:
> 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