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