Boost logo

Boost :

Subject: Re: [boost] [Stacktrace] Second review begins today 17th Mar ends 26th Mar
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-03-20 09:40:12


2017-03-20 2:42 GMT+01:00 Edward Diener via Boost <boost_at_[hidden]>:

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.

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;


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk