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

Subject: Re: [boost] [system][chrono] header-only libs
From: Marsh Ray (marsh_at_[hidden])
Date: 2010-10-13 16:27:30

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).

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