Re: [boost] [system][chrono] header-only libs

Subject: Re: [boost] [system][chrono] header-only libs
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-10-13 17:23:04

Hi,
----- Original Message ----- 
From: "Marsh Ray" <marsh_at_[hidden]>
To: <boost_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.
> 
> Suggestion:
> 
> #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
> 
> #endif
> 
> 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? 

Best,
Vicente