Boost logo

Boost :

Subject: Re: [boost] [system][chrono] header-only libs
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2010-10-13 18:07:27

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


Author of C++ Concurrency in Action
just::thread C++0x thread library   
Just Software Solutions Ltd
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

Boost list run by bdawes at, gregod at, cpdaniel at, john at