Re: [boost] [winapi] Problem with the latest clang on Windows

Subject: Re: [boost] [winapi] Problem with the latest clang on Windows
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-06-07 19:12:19

On 5/06/2015 20:31, Andrey Semashev wrote:
> On Friday 05 June 2015 19:04:51 Gavin Lambert wrote:
>>
>> What is the reason that Boost WinAPI redeclares the structure?  Can it
>> be changed to just use the one from the Windows headers (perhaps via
>> typedef, if the internal typename is needed for compatibility)?
>>
>> (After writing the above, a cursory glance at the code suggests that it
>> does do that if BOOST_USE_WINDOWS_H is defined.  So that changes the
>> question: under what conditions is that not defined?)
>
> The reason of Boost.WinAPI existence is that people don't want to include
> windows.h, especially in public headers. It is a heavy header that brings in
> most of SDK. It depends on predefined macros, so including it once defines the
> API users will be able to use; this is inconvenient for both Boost and its
> users. Also, windows.h defines a few offending macros, like min/max.

I'm not sure why this is a desirable goal.  Any user application is 
almost guaranteed to #include <windows.h> at some point -- it's the 
platform header, you can't really accomplish anything of value without 
doing so at some point, except in very trivial cases.  (Just like any 
non-trivial Linux app is likely to include one of the sys/ headers at 
some point.)

And typically this is in precompiled headers such that the cost of doing 
so is zero.

min/max issues are solved by using NOMINMAX or by using (std::min)(...) 
or the long-winded BOOST_PREVENT_MACRO_EXPANSION (or something like 
that; I forget the exact name, since I use the other approach).

Accidental conversion of method names from other top level macros (eg. 
SendMessage -> SendMessageW) are somewhat undesirable but the Boost 
naming conventions mean that this is never an issue for Boost code 
anyway... and even if it were, given that the user application will most 
likely be including windows.h then you'll actually be *causing* problems 
by trying to avoid picking up the WinAPI name.