On 19/03/2017 06:38, Antony Polukhin via Boost wrote:
2017-03-18 17:39 GMT+03:00 Peter Dimov via Boost <boost@lists.boost.org>:
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/