[pool] detail/mutex.hpp may include windows.h and pollute namespace with windows definitions.
I have been making an effort to write Windows independent code. In particular I avoid including windows.h in any of my headers (some implementation files include it). I have had a problem using Boost/pool as the mutex header includes windows.h (causing nameclashes with some of my existing code, which has always relied on the absence of windows.h). Possible inclusion of windows.h is documented in the section on mutex. My question is 'Is it really necessary or desirable ?'. Is there a Boost policy on the inclusion of OS specific headers which create a large number of declarations in the global namespace ? The section which uses windows.h is: #ifdef BOOST_WINDOWS class win32_mutex { private: ::CRITICAL_SECTION mtx; win32_mutex(const win32_mutex &); void operator=(const win32_mutex &); public: win32_mutex() { ::InitializeCriticalSection(&mtx); } ~win32_mutex() { ::DeleteCriticalSection(&mtx); } void lock() { ::EnterCriticalSection(&mtx); } void unlock() { ::LeaveCriticalSection(&mtx); } }; #endif // defined(BOOST_WINDOWS) I believe that the appropriate declarations of InitializeCriticalSection, DeleteCriticalSection, EnterCriticalSection, LeaveCriticalSection could be provided explicitly in this file and hence avoid including windows.h and the subsequent namespace 'pollution'. An alternative of using a Boost multithreading library is suggested in the documentation. This would be ideal, but my proposal would solve problem now, relatively effortlessly. PS. I did a quick edit and got it to work (at least on Vista). The change to the if-endif block is shown below. It could be done much better. # ifdef BOOST_WINDOWS //#include <windows.h> typedef char CRITICAL_SECTION[24]; //24 is sizeof(CRITICAL_SECTION) ! typedef CRITICAL_SECTION *LPCRITICAL_SECTION; #define WINAPI __stdcall extern void WINAPI InitializeCriticalSection( __out LPCRITICAL_SECTION lpCriticalSection ); extern void WINAPI DeleteCriticalSection( __inout LPCRITICAL_SECTION lpCriticalSection ); extern void WINAPI EnterCriticalSection( __inout LPCRITICAL_SECTION lpCriticalSection ); extern void WINAPI EnterCriticalSection( __inout LPCRITICAL_SECTION lpCriticalSection ); void WINAPI LeaveCriticalSection( __inout LPCRITICAL_SECTION lpCriticalSection ); # endif many regards, Paul
AMDG On 10/5/2010 8:04 AM, Paul Blampspied wrote:
I believe that the appropriate declarations of InitializeCriticalSection, DeleteCriticalSection, EnterCriticalSection, LeaveCriticalSection could be provided explicitly in this file and hence avoid including windows.h and the subsequent namespace 'pollution'. An alternative of using a Boost multithreading library is suggested in the documentation. This would be ideal, but my proposal would solve problem now, relatively effortlessly. PS. I did a quick edit and got it to work (at least on Vista). The change to the if-endif block is shown below. It could be done much better.
# ifdef BOOST_WINDOWS
//#include<windows.h>
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?
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". In Christ, Steven Watanabe
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.
On 10/08/2010 12:03 PM, Paul Blampspied wrote:
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?
Yes, it does link, and appears to work, at least under Vista. I took the declaration directly from Windows API documentation.
My guess is that reflects 3 or 6 uintptr_t values (I didn't see if it was x86 or x64). However, nearly every Windows program in the world has this size and alignment dependency compiled into it. Once you get the correct requirements (or larger), they won't change.
I could not find a declaration for CRITICAL_SECTION.
It's probably in the DDK in detail, but must be in the normal SDK somewhere.
I am sure there are better ways of doing this.
Not really :-( Typically, the developer supplying a header files for a Windows library assumes the app developer will have already included windows.h.
I think the important thing is to avoid including windows.h, which defines a huge number of symbols and can break code.
Yes, absolutely. It also doesn't compile as standard C or C++. As a long-time Win32 programmer who's run into this many times my conclusion is give up on the idea of including windows.h anywhere except consistently at the top of every translation unit that possibly needs it. Windows apps universally use precompiled headers for this and any other order of inclusion isn't well supported. This is also a general problem with any header that specifies "#define X before #including this header so it will behave a certain way". I'm surprised it's not a well known coding no-no.
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.
And MIN and MAX. I'll never forget the weird compile error I got when defined my own thing called TOKEN_TYPE. - Marsh
On Sat, Oct 9, 2010 at 5:04 AM, Marsh Ray <marsh@extendedsubset.com> wrote:
On 10/08/2010 12:03 PM, Paul Blampspied wrote:
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?
Yes, it does link, and appears to work, at least under Vista. I took the declaration directly from Windows API documentation.
My guess is that reflects 3 or 6 uintptr_t values (I didn't see if it was x86 or x64).
However, nearly every Windows program in the world has this size and alignment dependency compiled into it. Once you get the correct requirements (or larger), they won't change.
I could not find a
declaration for CRITICAL_SECTION.
It's probably in the DDK in detail, but must be in the normal SDK somewhere.
I am sure there are better ways of doing this.
Not really :-(
Typically, the developer supplying a header files for a Windows library assumes the app developer will have already included windows.h.
I think the important thing
is to avoid including windows.h, which defines a huge number of symbols and can break code.
Yes, absolutely. It also doesn't compile as standard C or C++.
As a long-time Win32 programmer who's run into this many times my conclusion is give up on the idea of including windows.h anywhere except consistently at the top of every translation unit that possibly needs it. Windows apps universally use precompiled headers for this and any other order of inclusion isn't well supported.
This is also a general problem with any header that specifies "#define X before #including this header so it will behave a certain way". I'm surprised it's not a well known coding no-no.
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.
And MIN and MAX.
I'll never forget the weird compile error I got when defined my own thing called TOKEN_TYPE.
- Marsh
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Your code won't work when compiled for x64. Here's the proper definition (Ripped from WinNT.h): #pragma pack(push, 8)
typedef struct _RTL_CRITICAL_SECTION {
PRTL_CRITICAL_SECTION_DEBUG DebugInfo;
//
// The following three fields control entering and exiting the
critical
// section for the resource
//
LONG LockCount;
LONG RecursionCount;
HANDLE OwningThread; // from the thread's ClientId->UniqueThread
HANDLE LockSemaphore;
ULONG_PTR SpinCount; // force size on 64-bit systems when packed
} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;
#pragma pack(pop)
HANDLE is always the size of a pointer. LONG is always 4-bytes under Windows. ULONG_PTR is the size of a pointer. PRTL_CRITICAL_SECTION_DEBUG is obviously the size of a pointer. Also, notice the explicit packing. So, a definition which does not required the Windows headers would be as follows: #pragma pack(push, 8)
typedef struct _RTL_CRITICAL_SECTION
{ void* DebugInfo; long LockCount; long RecursionCount; void* OwningThread; void* LockSemaphore; void* SpinCount; } RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;
#pragma pack(pop)
On 10/09/2010 06:19 AM, Joshua Boyce wrote:
So, a definition which does not required the Windows headers would be as follows:
#pragma pack(push, 8)
typedef struct _RTL_CRITICAL_SECTION
{
void* DebugInfo;
long LockCount;
long RecursionCount;
void* OwningThread;
void* LockSemaphore;
void* SpinCount;
} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;
#pragma pack(pop)
Suggestion: namespace boost { namespace boost_windows_h { #pragma pack(push, 8) struct RTL_CRITICAL_SECTION { void * reserved1; long reserved2; long reserved3; void * reserved4; void * reserved5; void * reserved6; }; typedef RTL_CRITICAL_SECTION * PRTL_CRITICAL_SECTION; #pragma pack(pop) } } The 'typedef struct' thing is a holdover from C. No reason to keep that struct tag, I don't think intended for use. Leading underscores are reserved for compiler vendors (like Microsoft) and organizations that ship non-standard headers (like Microsoft). The field data seems to change with OS versions, so code is not supposed to rely on it. The fields are effectively reserved. Personally, I'd use a lowercase struct name (it's not a macro after all) and omit the silly typedef. I'd be less concerned with it looking like the official headers if the point is to not include them. Just re-use the minimum needed for compatibility, which in this case is just sizeof() and __alignof(). - Marsh
Marsh Ray wrote:
On 10/09/2010 06:19 AM, Joshua Boyce wrote:
#pragma pack(push, 8)
typedef struct _RTL_CRITICAL_SECTION { void* DebugInfo; long LockCount;
[snip]
} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;
#pragma pack(pop)
Suggestion:
namespace boost { namespace boost_windows_h { #pragma pack(push, 8) struct RTL_CRITICAL_SECTION { void * reserved1; long reserved2; long reserved3; [snip] }; typedef RTL_CRITICAL_SECTION * PRTL_CRITICAL_SECTION; #pragma pack(pop) } }
The 'typedef struct' thing is a holdover from C.
No reason to keep that struct tag, I don't think intended for use. Leading underscores are reserved for compiler vendors (like Microsoft) and organizations that ship non-standard headers (like Microsoft).
The field data seems to change with OS versions, so code is not supposed to rely on it. The fields are effectively reserved.
Personally, I'd use a lowercase struct name (it's not a macro after all) and omit the silly typedef. I'd be less concerned with it looking like the official headers if the point is to not include them. Just re-use the minimum needed for compatibility, which in this case is just sizeof() and __alignof().
Those suggestions appear reasonable, but there are a couple of additional things that would be in order. First, rather than using unsized types and assuming they are and will always remain the expected size, use typed sizes like int32_t. One could even collapse the structure further by using one int64_t in place of the two (assumed) 32 bit longs. Given the use of void *'s for the other fields, presumably the structure's size varies between 32 and 64 bit platforms, so the same could not be done for those fields so neatly. Second, add a test to ensure that the size of the fabricated proxy is the same as the real thing. That will ensure that the definition remains appropriate for all platforms present and future. Since the test will be in compiled code that doesn't affect the header, it can safely include windows.h to get the real definition. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Mon, Oct 11, 2010 at 10:15 PM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
Marsh Ray wrote:
On 10/09/2010 06:19 AM, Joshua Boyce wrote:
#pragma pack(push, 8)
typedef struct _RTL_CRITICAL_SECTION { void* DebugInfo; long LockCount;
[snip]
} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;
#pragma pack(pop)
Suggestion:
namespace boost { namespace boost_windows_h { #pragma pack(push, 8) struct RTL_CRITICAL_SECTION { void * reserved1; long reserved2; long reserved3; [snip] }; typedef RTL_CRITICAL_SECTION * PRTL_CRITICAL_SECTION; #pragma pack(pop) } }
The 'typedef struct' thing is a holdover from C.
No reason to keep that struct tag, I don't think intended for use. Leading underscores are reserved for compiler vendors (like Microsoft) and organizations that ship non-standard headers (like Microsoft).
The field data seems to change with OS versions, so code is not supposed to rely on it. The fields are effectively reserved.
Personally, I'd use a lowercase struct name (it's not a macro after all) and omit the silly typedef. I'd be less concerned with it looking like the official headers if the point is to not include them. Just re-use the minimum needed for compatibility, which in this case is just sizeof() and __alignof().
Those suggestions appear reasonable, but there are a couple of additional things that would be in order.
First, rather than using unsized types and assuming they are and will always remain the expected size, use typed sizes like int32_t. One could even collapse the structure further by using one int64_t in place of the two (assumed) 32 bit longs. Given the use of void *'s for the other fields, presumably the structure's size varies between 32 and 64 bit platforms, so the same could not be done for those fields so neatly.
Second, add a test to ensure that the size of the fabricated proxy is the same as the real thing. That will ensure that the definition remains appropriate for all platforms present and future. Since the test will be in compiled code that doesn't affect the header, it can safely include windows.h to get the real definition.
_____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Microsoft document the sizes of various types on MSDN, and given the backwards-compatibility guarantees offered by the Windows API they can't really change them. http://msdn.microsoft.com/en-us/library/s3f49ktz.aspx http://msdn.microsoft.com/en-us/library/cc953fe1.aspx Not to say that it would be a bad idea to use sized types 'just in case'. I'm all for it. I'm just saying, all the Windows compilers I use (MSVC, GCC via MinGW, and ICC) 'adhere' to those size lists, and I can't really see a situation where that would change, as it would break so much existing code. Sorry if I'm not being very articulate. Quite tired, and about to hit the sack. P.S. There's no reason to use sized types for the arguments which we're using pointers for, as the 'real' types are just DWORD_PTR/ULONG_PTR/etc which are guaranteed to be the same size as a pointer anyway.
Thanks to all responders for the information. Conclusion is that it is possible to rely on the size and alignment of CRITICAL_SECTION not changing. I have to implement this edit to the library for my own purposes, as windows.h is conflicting with too much code (including other libraries which I do not want to modify). Ray's point about MIN and MAX macros is well taken. These macros caused me problems too. I did not mention them because it is possible to avoid by defining NOMINMAX in the project file. The Boost documentation does say that the use of Windows critical sections is an interim measure pending a portable Boost implementation of equivalent features. This means that it may not be worth making any changes to the library until the job can be done properly. I suspect this won't be too long as Boost has recently increased it's portable support for thread synchronisation. regards, Paul
On 10/11/2010 06:15 AM, Stewart, Robert wrote:
Marsh Ray wrote:
#pragma pack(push, 8) struct RTL_CRITICAL_SECTION { void * reserved1; long reserved2; long reserved3;
First, rather than using unsized types and assuming they are and will always remain the expected size, use typed sizes like int32_t. One could even collapse the structure further by using one int64_t in place of the two (assumed) 32 bit longs. Given the use of void *'s for the other fields, presumably the structure's size varies between 32 and 64 bit platforms, so the same could not be done for those fields so neatly.
On one hand, we could look at it as "void*" and "long" are the underlying types that MS chose to use for <windows.h>, so they are correct by definition. On the other hand, even MS couldn't increase the size of a long when going to 64 bits due to exactly this kind of thing. So in practice, any compiler that wishes be able to compile Win32/64 code is going to have to match the sizes of the basic types. Forever.
Second, add a test to ensure that the size of the fabricated proxy is the same as the real thing. That will ensure that the definition remains appropriate for all platforms present and future.
Seriously, windows.h considers itself the 900-pound gorilla. The inclusion of that header defines the platform, even to the point of requiring nonstandard language extensions. It was mostly solidified the early '90s. Most APIs are not particularly type-safe and there are many that are not even const-correct. I suggest not trying to reason about C++ best practices to the standard usually done with Boost projects.
Since the test will be in compiled code that doesn't affect the header, it can safely include windows.h to get the real definition.
Doesn't worth an extra source project to me. If the size of such a simple and fundamental structure comes out wrong, so much other stuff isn't going to work that I doubt the compiler could even emit a loadable module. On 10/11/2010 12:13 PM, Paul Blampspied wrote:
Ray's point about MIN and MAX macros is well taken. These macros caused me problems too. I did not mention them because it is possible to avoid by defining NOMINMAX in the project file.
What's a "project file"? (Well, I know what you're talking about but it's not a standard feature of C++ and lots of stuff doesn't use them. E.g., Boost.) Also, consider that there may be code somewhere that relies on them. Include-once headers that change behavior based on preprocessor definitions are fundamentally evil.
The Boost documentation does say that the use of Windows critical sections is an interim measure pending a portable Boost implementation of equivalent features.
They're going to need to use the underlying OS facilities one way or another. On Windows, that's kernel mutexes and critical sections (which can be faster).
This means that it may not be worth making any changes to the library until the job can be done properly. I suspect this won't be too long as Boost has recently increased it's portable support for thread synchronisation.
Rest assured that you are not the first, and will not be the last, to restate basic declarations to avoid brokenness introduced by the inclusion of windows.h. Ideally, this stuff would accumulate under a permissive license (public domain even) so that others could re-use it. - Marsh
Marsh Ray wrote:
On 10/11/2010 06:15 AM, Stewart, Robert wrote:
Marsh Ray wrote:
#pragma pack(push, 8) struct RTL_CRITICAL_SECTION { void * reserved1; long reserved2; long reserved3;
First, rather than using unsized types and assuming they are and will always remain the expected size, use typed sizes like int32_t. One could even collapse the structure further by using one int64_t in place of the two (assumed) 32 bit longs. Given the use of void *'s for the other fields, presumably the structure's size varies between 32 and 64 bit platforms, so the same could not be done for those fields so neatly.
On one hand, we could look at it as "void*" and "long" are the underlying types that MS chose to use for <windows.h>, so they are correct by definition. On the other hand, even MS couldn't increase the size of a long when going to 64 bits due to exactly this kind of thing. So in practice, any compiler that wishes be able to compile Win32/64 code is going to have to match the sizes of the basic types. Forever.
I don't disagree, but for the non-Windows developer, that won't be obvious and the non-Windows-centric assumptions can be made self documenting by using sized types.
Second, add a test to ensure that the size of the fabricated proxy is the same as the real thing. That will ensure that the definition remains appropriate for all platforms present and future.
Seriously, windows.h considers itself the 900-pound gorilla. The inclusion of that header defines the platform, even to the point of requiring nonstandard language extensions. It was mostly solidified the early '90s. Most APIs are not particularly type-safe and there are many that are not even const-correct. I suggest not trying to reason about C++ best practices to the standard usually done with Boost projects.
Thanks for the history lesson, but I think you missed the point. The Boost proxy for what's in windows.h could be wrong due to any sort of maintenance activity or funny platform specifics that haven't been divined at present. Adding a test to verify the size increases confidence.
Since the test will be in compiled code that doesn't affect the header, it can safely include windows.h to get the real definition.
Doesn't worth an extra source project to me. If the size of such a simple and fundamental structure comes out wrong, so much other stuff isn't going to work that I doubt the compiler could even emit a loadable module.
To what extra project do you refer? There are tests already for the library, so this is just adding one to ensure the proxy has the right size. It is that test, which would only do anything useful on Windows builds, that would include windows.h. Where's the problem? What's more, one wants a test that clearly points to a problem rather than a raft of errors from numerous unrelated tests to wade through to discover the problem. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 10/11/2010 02:10 PM, Stewart, Robert wrote:
Marsh Ray wrote:
On one hand, we could look at it as "void*" and "long" are the underlying types that MS chose to use for<windows.h>, so they are correct by definition. On the other hand, even MS couldn't increase the size of a long when going to 64 bits due to exactly this kind of thing. So in practice, any compiler that wishes be able to compile Win32/64 code is going to have to match the sizes of the basic types. Forever.
I don't disagree, but for the non-Windows developer, that won't be obvious and the non-Windows-centric assumptions can be made self documenting by using sized types.
Still, there's something to be said for a simple C struct, and we should keep in mind that this struct is even supposed to be opaque. I remember chasing down weird template instantiation problems deriving from the fact that one part of the code was using a 'uint32_t' type typedef'ed from 'int' while another was typedefed from 'long'.
Thanks for the history lesson, but I think you missed the point.
Haha, quite possibly. I'm usually the last guy to argue against verification code, especially compile time checks, so I probably agree with what you're saying more than what I'm saying. :-) But nonetheless, I'll try to clarify.
The Boost proxy for what's in windows.h could be wrong due to any sort of maintenance activity
At some point, one has to be able to trust that: #pragma pack(8) struct s { void* u; long v; long w; void* x; void* y; void* z; }; isn't going to change out from under us. Or if it could change, the thing you test it with could also change in the wrong way, too.
or funny platform specifics that haven't been divined at present.
In my experience, this just isn't going to be a problem. In order to produce Win32 executables, the compiler will have to support Win32 structure layout and API calling conventions. On the other hand, in theory we might need an extern "C" around that.
Adding a test to verify the size increases confidence. [...] There are tests already for the library, so this is just adding one to ensure the proxy has the right size. It is that test, which would only do anything useful on Windows builds, that would include windows.h. Where's the problem?
I'd greatly prefer not to need a Windows SDK to build and use Boost successfully, even with a Windows compiler. If it's for a test which I can easily skip or ignore, obviously that's not a big deal. Just to give you a little background on my perspective: I currently have a 264 line text document with notes on how to build a new release of Boost for use in our production stuff. Some of that is just unavoidable source control commands, but some of it is to cut down on bulk by separating out just the necessary headers and .libs from other source, docs, and test code. Also, I use some particular compiler settings to ensure that Boost static libs don't drag in unwanted dependencies which cause the resulting executables to depend on multiple versions of MSVCRT and fail to load mysteriously on 1 in 20 customer machines. So you can see why I might suggest that adding a dependency on windows.h (possibly the largest C header in the world) could be just possibly be more trouble than it's worth for a simple test of things that are likely to fail loudly anyway.
What's more, one wants a test that clearly points to a problem rather than a raft of errors from numerous unrelated tests to wade through to discover the problem.
Yep, can't argue with that. - Marsh
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just in case it hasn't been mentioned already, it might be helpful to look at boost/smart_ptr/detail/lwm_win32_cs.hpp as it seems to handle the "critical section with or without windows.h" issue already. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAky8Y5MACgkQ5vihyNWuA4WpmQCgkWFDXF92spVQYum+TC6iLQ/k HkUAmwSIFncB9SwKDqEYNmnX8oLPKqsB =Xs0f -----END PGP SIGNATURE-----
----- Original Message ----- From: "Frank Mori Hess" <frank.hess@nist.gov> To: <boost@lists.boost.org> Sent: Monday, October 18, 2010 5:11 PM Subject: Re: [boost] [pool] detail/mutex.hpp may include windows.h andpollute namespace with windows definitions.
Just in case it hasn't been mentioned already, it might be helpful to look at boost/smart_ptr/detail/lwm_win32_cs.hpp as it seems to handle the "critical section with or without windows.h" issue already.
Hi, I have proposed to put some files that avoid the inclusion of <windows.h> file in the boost/detail/win directory (See thread [system][chrono] header only libs" <http://boost.2283326.n4.nabble.com/system-chrono-header-only-libs-td2992903.html#a2992903>) For the moment I have started with the files needed to make Boost.System and Boost.Chrono header only without including windows.h. I propose to move all the definitions as the ones in * boost/date_time/filetime_functions.hpp * boost/detail/interlocked.hpp * boost/flyweight/detail/process_id.hpp * boost/interprocess/detail/win32_api.hpp * boost/smart_ptr/detail/lwm_win32_cs.hpp * boost/thread/win32/thread_heap_alloc.hpp * boost/thread/win32/thread_primitives.hpp to this directory so we can share them in a centralized way for all the Boost libraries. In order to ensure that the types corresponds to the ones in windows.h some test must be added, so we can be confident that the layout is the same. Anyone wanting to joint this effort is welcome :-) Comments on the current approach? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/
participants (7)
-
Frank Mori Hess -
Joshua Boyce -
Marsh Ray -
Paul Blampspied -
Steven Watanabe -
Stewart, Robert -
vicente.botet