Subject: Re: [boost] [Stacktrace] Second review begins today 17th Mar ends 26th Mar
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-03-20 01:42:43
On 3/19/2017 7:30 PM, Niall Douglas via Boost wrote:
>> Peter did not suggest not using windows.h itself AFAICS. He just
>> suggested that stacktrace functionality which does not need it be
>> segregated into specific headers which do not include it. Furthermore if
>> stacktrace still has the general header, and promotes the use of it,
>> rather than specific headers, that's fine as long as the end-user has a
>> choice. OTOH if stacktrace functionality which appears not to need the
>> constructs in windows.h still does need it under the covers in the
>> header only version of the library, then I understand Antony's objection.
> If you choose the null backend, then yes windows.h should not be included.
> If you choose the non-null backend, which needs to open up a COM session
> with the Debug Engine to debug the calling executable, I think windows.h
> (and the COM headers which are also massive) pretty hard to avoid.
Choosing only the windbg backend needs COM. I am still arguing along
with Peter that merely choosing the windbg backend, or having it
automatically chosen for me when I am using VC++, should not bring in
windows.h until it is actually needed by the code I am invoking either
in the stacktrace or frame classes.
I can see using stacktrace where I am just passing already generated
stacktrace or frame objects and once COM is needed to produce
stacktraces or frames I see no reason why windows.h must be included in
header files that do not need that functionality which generated the
appropriate information anymore.
> And for the record, I too feel little love for windows.h, though they do
> provide NOMINMAX and WIN32_LEAN_AND_MEAN to make the problem less awful.
> One HUGE win with C++ Modules will be that we can finally work around
> windows.h once and for all.