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

[per at lumai.se]

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?

-- 
Per Lindén

Jesse Towner skrev 2010-08-05 18:12:
> Yeah, Windows.h sure brings in a lot of dependencies, no one will deny
> that.. One thing I've seen done on some projects before that needed to
> pull in some declaration from Windows.h into project headers without
> polluting the global namespace is to redeclare them nested inside of a
> private namespace.
>
> Example:
>
> // some_project/threading/windows/mutex.hpp
>
> namespace some_project
> {
>     namespace detail
>     {
>         namespace windows
>         {
> #pragma pack(push, 8)
>             struct CRITICAL_SECTION
>             {
>                 void* debug_info;
>                 long lock_count;
>                 long recursion_count;
>                 void* owning_thread;
>                 void* lock_semaphore;
>                 uintptr_t spin_count;
>             };
> #pragma pack(pop)
>
>             extern "C" __declspec(dllimport) int __stdcall
> InitializeCriticalSectionEx(CRITICAL_SECTION*, unsigned long, unsigned
> long);
>             extern "C" __declspec(dllimport) void __stdcall
> EnterCriticalSection(CRITICAL_SECTION*);
>             extern "C" __declspec(dllimport) void __stdcall
> LeaveCriticalSection(CRITICAL_SECTION*);
>             extern "C" __declspec(dllimport) unsigned long __stdcall
> SetCriticalSectionSpinCount(CRITICAL_SECTION*, unsigned long);
>             extern "C" __declspec(dllimport) int __stdcall
> TryEnterCriticalSection(CRITICAL_SECTION*);
>             extern "C" __declspec(dllimport) void __stdcall
> DeleteCriticalSection(CRITICAL_SECTION*);
>             // etc.
>         }
>     }
>
>     // ...
>     // use it
>
>     class mutex
>     {
>     public:
>
>         // ...
>
>         void lock() {
>             detail::windows::EnterCriticalSection(&mutex_);
>         }
>
>     private:
>
>         detail::windows::CRITICAL_SECTION mutex_;
>     };
> }
>
> Of course, the problem with this is you suddenly need to maintain all of
> these prototypes and type definition and make sure they match up with
> the Windows ABI, and you need to do it for multiple target
> architectures. Fortunately, Windows is fairly stable in this regard, so
> once you do get it working, you usually don't need to look at it again.
> Another good thing is that it doesn't necessarily interfere later on
> when you do include Windows.h in an actual translation unit. I'm not
> sure if something like this might be helpful. Just an idea.
>
> - Jesse Towner
>
> On Thu, Aug 5, 2010 at 8:43 AM, per at lumai.se
> <mailto:per at lumai.se> <per at lumai.se
> <mailto:per at lumai.se>> wrote:
>  > Francois Pichet skrev 2010-08-05 17:33:
>  >> use it is not a predefined macro. It is generally defined in
>  >> stdafx.h and some projects actually need to compile wit
>  >
>  > Yeah, I was not sure about whether that one was a good idea. The thing
>  > is that it's the simplest fix I found to stop that IID_PPV_ARGS_Helper
>  > mess from breaking builds in C++ mode without editing the SDK files. The
>  > best thing would of course be non-broken headers from M$... The other
>  > two defines would be OK, right?
>  >
>  > My goal is to get libcxx through clang in the MSVC environment and it
>  > uses sockets which of course pull in windows.h, as everything else
>  > does... The dependence on non-MS-supported C99 library functions in
>  > libcxx are yet another issue to work around...
>  >
>  > --
>  > Per Lindén