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

Francois Pichet pichet2000 at gmail.com
Sun Aug 8 05:33:40 PDT 2010


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
>
> John McCall skrev 2010-08-06 20:16:
>> On Aug 6, 2010, at 10:55 AM, Francois Pichet wrote:
>>> This is required to parse MFC/ATL header. A large percentage of
>>> Windows C++ applications depend on those. Just the core system headers
>>> I am not sure yet.
>>
>> Unfortunately, MFC definitely counts as a system header.  I don't know Windows
>> programming well;  I was hoping that those classes wouldn't be heavily templated.
>> If you can get us test cases, we can try to design something that won't frightfully
>> abuse the rest of the system.  Maybe we can get away with setting the default to
>> have an opt-in set of permissively-parsed templates.
>>
>> I guess we were lucky with GCC compatibility because the system headers are
>> predominantly C (+ Objective C on Darwin).  We do actually have problems with
>> certain versions of the Qt headers, I think, but it's easier to discount those as
>> non-system.
>>
>> John.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>




More information about the cfe-dev mailing list