2017-03-20 2:42 GMT+01:00 Edward Diener via Boost
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.
Maybe this could be fixed by providing two windows backends: the current one, plus another one that offers a limited functionality but does not include the COM stuff? This would give a control to the users over the trade-off. Regards, &rzej;