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