Re: [boost] [Stacktrace] Second review begins today 17th Mar ends 26th Mar

Subject: Re: [boost] [Stacktrace] Second review begins today 17th Mar ends 26th Mar
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-03-19 09:34:23

On 19/03/2017 06:38, Antony Polukhin via Boost wrote:
> 2017-03-18 17:39 GMT+03:00 Peter Dimov via Boost <boost_at_[hidden]>:
>> Antony Polukhin wrote:
>>
>>> windows.h is a minor problem of a single platform.
>>
>>
>> windows.h is not a minor problem at all. It defines one million macros.
> 
> dbgeng.h defines 10M macros. Getting rid of windows.h solves only
> small part of the problem.
> 
> Looks like the right solution would be not to minify headers that use
> the windbh.h/dbgeng.h but rather write a correct forward declarations
> of windbh.h/dbgeng.h stuff, just like Boost.WinAPI does.
> 
> My COM knowledge is limited, so I'd *really appreciate* some help with
> dbgeng.h. This will also fix multiple MinGW issues and will allow a
> better MinGW (and even Clang on Win) stacktracing out of the box.
> 
> I'll take care of windows.h stuff soon.

Putting on my review manager hat, here is my position on <windows.h>:

1. The size of windows.h is Microsoft's fault, not the code which
includes it.

2. *Gratuitous* includes of windows.h is a showstopper for a high
quality library, so including windows.h just for one or two APIs is a
bad thing.

3. If however a library really makes extensive use of windows.h and if
the user prefers the header only edition of the library, then including
all of windows.h is *the price they pay*. They have the choice: either
go header only and include windows.h, or don't go header only and don't
include it.

4. In case anyone thinks I'm being unreasonably lax here, nobody much
complains about header only inclusion of <sys/unistd.h> etc. That's
because the size of <windows.h> is *Microsoft's fault*. It's the cost
they impose on every Windows dev. We library developers are not at
fault. Blame Microsoft.

5. I think it's highly unreasonable to ask Antony to remove windows.h
from the headers only build. The Windows backend unavoidably uses COM
with all that magic compiler-specific GUID attribute markup and such
fun, and the headers brought in are auto generated from COM IDL and hand
tuned by Microsoft. Hacking that out just to tick a box for some people
will produce a much more brittle, unreliable and hard to maintain library.

I as review manager certainly will not stop Stacktrace entering Boost on
this point. If anything, if Antony ruins the library just to eliminate
<windows.h> inclusion, I'd actually recommend its rejection.
I appreciate that this will not be a popular opinion, but I'm the review
manager and that's my judgement on it.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/