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: Marsh Ray (marsh_at_[hidden])
Date: 2010-10-11 16:16:31

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