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

[Per Lindén]

I am using windows.h from MS SDK 6.0a with VS 2008 SP1. I defined 
WIN32_LEAN_AND_MEAN to get rid of the IID_PPV_ARGS_Helper/IUnknown 
template issues and defined __STDC__ to get rid of "bool" used as struct 
member name, although it's not a final solution. Some comments about 
your issues:

1 - It should not be too hard to find out which macros are actually 
predefined by the compiler and which are defined in headers, right? 
Either by string searching the headers or creating a file that 
dereferences all the mentioned macros without including anything and 
then preprocessing it with cl.exe?

2 - My personal opinion is that many (most?) of the macros can be 
ignored until they actually cause a problem. Most of them seem to have 
little or no impact on the standard headers. If someone has a problem 
with an exotic define, let them post a bug and consider adding support 
at that time? As long as a user can use clang -D <exotic_macro> they 
should be OK at least for a while?

-- 
Per Lindén

Francois Pichet skrev 2010-08-08 14:33:
> I am curious about what version of Windows.h are you using?
> I did some test using Visual Studio 2008 Windows headers and I
> couldn't compile correctly using clang. The problems I got are not
> related to predefined macros so I investigated that instead.
>
> I am not ready to submit anything yet. 2 issues:
>
> 1- Many of the so called predefined macro documented here
> (http://msdn.microsoft.com/en-us/library/b0084kay(VS.90).aspx) are not
> predefined macros at all but instead defined deep within the MSVC
> header files with normal #define. As such they should not be
> predefined in CLang.
>
> 2-  Many MSVC predefined macros depends on various command line
> switches. CLang doesn't recognize those switches. As such I am not
> sure what to do exactly.
>
>
> On Sat, Aug 7, 2010 at 8:41 AM, per at lumai.se<per at lumai.se>  wrote:
>    
>> I would say MFC/ATL appears to be a LONG term goal. I have several
>> non-MFC (Win32-)projects that would benefit from this as long as the
>> basic system headers work (windows.h etc). This would also allow
>> non-trivial command line apps to work. Also, starting from a low
>> _MSC_VER (1200?) and then working upwards would reduce the number of new
>> extensions needed before getting anything to build. The number of
>> template-related problems would also be manageable (if one uses libc++,
>> that is...) The so-called "standards compliant" Dinkumware STL in VS2008
>> has a bunch of clang-problematic templates such as missing "typename".
>>
>> --
>> Per Lindén
>>