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