rm5248 commented on PR #170: URL: https://github.com/apache/logging-log4cxx/pull/170#issuecomment-1365317171
> > The reason I didn't make separate macros is that I don't want to change log statements if I now want a stack trace. > > What situation you are thinking of where adding a stack-trace to pre-existing log statements would be useful? It hasn't come up for me for a while, but occasionally I do need to know what piece of code is calling a certain function, perhaps because a function is called a number of different places and I don't know how we got there. This can be easier than stepping through the debugger and hitting the same breakpoint 20 times. > Given that C++23 paper [A Proposal to add stacktrace library](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0881r3.html) is _only_ motivated by **assertions can't describe the whole picture of a bug**, perhaps the stacktrace should _only_ be added to the LOG4CXX_ASSERT macro. > That sounds reasonable to me; I will add some documentation on how you could add the stacktrace to normal log statements if you want that for whatever reason. > Then instead of `LOG4CXX_ENABLE_STACKTRACE` the macro would be `LOG4CXX_HAS_STACKTRACE` which is set by when `__cpp_lib_stacktrace` is defined and non-zero or if boost stacktrace is found by cmake. The advantage of the current implementation is that you don't need to have a new enough C++ standard or have Boost stacktrace installed when compiling log4cxx, which I do like in order to have it as just an optional dependency. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
