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