Subject: Re: [boost] [system][chrono] header-only libs
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-10-13 17:23:04
----- Original Message -----
From: "Marsh Ray" <marsh_at_[hidden]>
Cc: "vicente.botet" <vicente.botet_at_[hidden]>; "Ion Gaztañaga" <igaztanaga_at_[hidden]>
Sent: Wednesday, October 13, 2010 10:27 PM
Subject: Re: [system][chrono] header-only libs
> On 10/12/2010 06:37 PM, vicente.botet wrote:
>> While doing this I have found a minor issue on Windows platform. I
>> hve nedeed to sorrounded by () all the use of min and max functions
>> on the test files to avoid the macros defined on the windows.h file.
>> That means that a header-only lib could break user sources as it will
>> include implicitly some platform files.
> Normally, header files should include the headers which provide
> definitions that they need. Unfortunately, windows.h does not follow the
> conventions and coding standards needed for that to be a safe thing to do.
> 1. It requires nonstandard language extensions
> 2. It defines common macro names like MIN, MAX, and TOKEN_TYPE
> 3. It requires configuration via preprocessor definitions before its
> inclusion, and yet it has a top-level #ifndef header guard which
> prevents multiple inclusion.
> 4. Last I checked (some time time ago), it had order-of-inclusion
> problems with other common MS library headers (like MFC and ATL).
I'm not a Windows programmer, and I was unaware of this order-of-inclusion issue.
Boost.Interprocess and other libraries inlcude already <windows.h>, isn't it? have some authors found some trouble of this kind?
> The majority of Windows code seems to include windows.h from a
> precompiled header at the top of most every translation unit.
> #ifndef _WINDOWS_ // or _INC_WINDOWS or whatever works empirically
> # error "Please include windows.h before this header (without
> defining NOGDI or NOUSER)" // or whatever parts are needed
> As a long time Windows programmer, it seems entirely reasonable and
> unsurprising to me that a library header which depended on Windows OS
> features to expect that windows.h had been included ahead of time. I
> would prefer this over having mysterious order-of-inclusion issues with
> Boost headers. There will always be potential o-o-i issues with
> windows.h, but they can at least be made to result in a good explanation
> in the compiler output.
> - Marsh
What do others think of the proposed approach?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk