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-14 01:38:29

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, October 14, 2010 12:07 AM
Subject: Re: [boost] [system][chrono] header-only libs

> "vicente.botet" <vicente.botet_at_[hidden]> writes:
> 
>> From: "Marsh Ray" <marsh_at_[hidden]>
>>> 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.
>>
>> What do others think of the proposed approach? 
> 
> The approach taken in the boost.thread headers is to define the types
> and functions needed in a "detail" namespace rather than include
> <windows.h> directly, unless BOOST_USE_WINDOWS_H is defined. See for
> example <boost/thread/win32/thread_primitives.hpp>
> 
> Since the Windows API is a C API, the extern "C" declarations in the
> internal namespace will link against the global names provided by the
> library without publishing those names in the global namespace in files
> that include the header, or clashing with declarations from <windows.h>
> in those files that also include it.
> 
> This causes a bit of difficulty where the definitions vary between SDK
> versions, but this is generally OK.
> 
> Anthony

I understand that you should have found some issues including <windows.h> file. I see that other libraries as FileSystem, Flyweithts, Interprocess, interlocked ... include it as you said:

#if defined(BOOST_USE_WINDOWS_H)
#  include <windows.h>
#else
// extern declaration
#endif

Unfortunately not all files including <windows.h> are protected in this way. Is BOOST_USE_WINDOWS_H the offical macro to use? is this described somewhere?

As there are quite a lot of files that includes some parts of <windows.h> some of them include the same declarations. I was wondering if we can not add a boost/detail/windows.hpp> file that will declare whatever is needed in Boost. Is this a good or a bad idea? 

As other platforms include other macros, shouldn't I do the same for this files?

Thanks to both for signaling the trap and how to manage with.

Best,
Vicente