Re: [boost] [pool] detail/mutex.hpp may include windows.h and pollute namespace with windows definitions.

Subject: Re: [boost] [pool] detail/mutex.hpp may include windows.h and pollute namespace with windows definitions.
From: Paul Blampspied (elpidiovaldez5_at_[hidden])
Date: 2010-10-08 13:03:53

>
>
>>
>> typedef char CRITICAL_SECTION[24]; //24 is sizeof(CRITICAL_SECTION) !
>>
>
> Can you guarantee that this is the correct size
> on all systems?  Are you sure that there are
> no alignment problems?
>
>
>
No I can't guarantee it across all systems.  I made the edit to get
[Boost][pool] to work for my project, without including windows.h.  It would
need to be checked and, if necessary appropriate conditional code provided.

>  typedef CRITICAL_SECTION *LPCRITICAL_SECTION;
>>
>> #define WINAPI __stdcall
>>
>> extern void WINAPI InitializeCriticalSection(
>> __out LPCRITICAL_SECTION lpCriticalSection
>> );
>>
>
> Does this actually link?  I would think that it would
> need to be extern "C".

Yes, it does link, and appears to work, at least under Vista.  I took the
declaration directly from Windows API documentation.  I could not find a
declaration for CRITICAL_SECTION.

I am sure there are better ways of doing this.  I think the important thing
is to avoid including windows.h, which defines a huge number of symbols and
can break code.  One particular nasty is the __in_range macro which
conflicts with stlport's  checked iterators in debug builds.  A less risky
change might be to simply undefine some of the undocumented macros that
windows.h leaves behind it.  A judicious use of namespaces allows you to
avoid most of the other problems.