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