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.<br>
<br>Example:<br><br>// some_project/threading/windows/mutex.hpp<br><br>namespace some_project<br>{<br>    namespace detail<br>    {<br>        namespace windows<br>        {<br>#pragma pack(push, 8)<br>            struct CRITICAL_SECTION<br>
            {<br>                void* debug_info;<br>                long lock_count;<br>                long recursion_count;<br>                void* owning_thread;<br>                void* lock_semaphore;<br>                uintptr_t spin_count;<br>
            };<br>#pragma pack(pop)<br><br>            extern "C" __declspec(dllimport) int __stdcall InitializeCriticalSectionEx(CRITICAL_SECTION*, unsigned long, unsigned long);<br>            extern "C" __declspec(dllimport) void __stdcall EnterCriticalSection(CRITICAL_SECTION*);<br>
            extern "C" __declspec(dllimport) void __stdcall LeaveCriticalSection(CRITICAL_SECTION*);<br>            extern "C" __declspec(dllimport) unsigned long __stdcall SetCriticalSectionSpinCount(CRITICAL_SECTION*, unsigned long);<br>
            extern "C" __declspec(dllimport) int __stdcall TryEnterCriticalSection(CRITICAL_SECTION*);<br>            extern "C" __declspec(dllimport) void __stdcall DeleteCriticalSection(CRITICAL_SECTION*);<br>
            // etc.<br>        }<br>    }<br><br>   // ...<br>   // use it<br>   <br>   class mutex<br>   {<br>   public:<br><br>       // ...<br><br>       void lock() {<br>           detail::windows::EnterCriticalSection(&mutex_);<br>
       }<br><br>   private:<br><br>       detail::windows::CRITICAL_SECTION mutex_;<br>   };<br>}<br><br>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.<br>
<br>- Jesse Towner<br><br>On Thu, Aug 5, 2010 at 8:43 AM, <a href="mailto:per@lumai.se">per@lumai.se</a> <<a href="mailto:per@lumai.se">per@lumai.se</a>> wrote:<br>> Francois Pichet skrev 2010-08-05 17:33:<br>>> use it is not a predefined macro. It is generally defined in<br>
>> stdafx.h and some projects actually need to compile wit<br>><br>> Yeah, I was not sure about whether that one was a good idea. The thing<br>> is that it's the simplest fix I found to stop that IID_PPV_ARGS_Helper<br>
> mess from breaking builds in C++ mode without editing the SDK files. The<br>> best thing would of course be non-broken headers from M$... The other<br>> two defines would be OK, right?<br>><br>> My goal is to get libcxx through clang in the MSVC environment and it<br>
> uses sockets which of course pull in windows.h, as everything else<br>> does... The dependence on non-MS-supported C99 library functions in<br>> libcxx are yet another issue to work around...<br>><br>> --<br>
> Per Lindén<br>><br>> _______________________________________________<br>> cfe-dev mailing list<br>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br><br>