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: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-10-11 15:10:16

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_at_[hidden]
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.