Boost logo

Boost :

Subject: Re: [boost] [Stacktrace] Second review begins today 17th Mar ends 26th Mar
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2017-03-20 19:25:35


2017-03-20 4:42 GMT+03:00 Edward Diener via Boost <boost_at_[hidden]>:
> <...> and once COM is needed to produce
> stacktraces or frames <...>

It is required to produce anything useful from frame/stacktrace.
Following operations use COM (on MSVC only):
* ostreaming stacktrace
* ostreaming frame
* getting function name from frame
* getting source file location from frame
* getting line in source file from frame

Now everyone here agrees that windows.h and COM is bad. But extracting
out the windows.h/COM - is beyond my abilities. I'm not a lazy-bad-ass
that does not wish to remove windows.h just because I do not care. It
is because I've failed to do so. Such removal requires that all the
BOOST_STACKTRACE_*_tuning_macro+BOOST_FOCEINLINE+BOOST_NOINLINE+skip_frames
stuff must cooperate well on multiple platforms in header only and
link-library modes. Also I can not see how you're going to use the
library without 95% of functionality - I just do not understand what
functions to move in what places. Moreover, as I understand at least
two reviewers would like to have absolutely different functionality to
depend or not on windows.h

I'd gladly merge all the changes if some hero would produce a right
pull request. I've failed to produce such.

What is more important - moving away windows.h is a non breaking
change that does not change the library interface (API). So all the
messing with headers, moving code and attributes around could be done
any time later. Moreover, windows.h never was a stopper for inclusion.
'find -name "*.hpp" -print0 | xargs -0 grep "windows\.h"' yields 14
libraries that use windows.h in header files.

Now, when everyone agrees that windows.h is bad but nobody has the
will or knowledge to fix it, let's review the remaining parts of the
library.

-- 
Best regards,
Antony Polukhin

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