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

Jesse Towner townerj at gmail.com
Thu Aug 5 09:12:31 PDT 2010


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 <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
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100805/f427933d/attachment.html>


More information about the cfe-dev mailing list