2017-03-20 4:42 GMT+03:00 Edward Diener via Boost
<...> 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