I see that Boost.stacktrace is up for review March 17, 2017 - March 26, 2017 I've got some broad feedback. I'm in a race to comment before I go on vacation on Friday, so I'm sorry if I've missed something or misunderstood. I will try and follow the thread while on vacation - but not sure that will happen. 1) Resolving function names can be VERY expensive. Potentially it requires multi-megabyte files to be loaded and parsed. It is not clear to me that the resolution of frame.name() is going to be deferred. I have written a _lot_ of stack tracing code, and have usually in practice needed something that is fast and efficient to collect stack trace(s), but which allows deferring of the cost of resolving symbolic information until I really need it. In the extreme example I had some code which speculatively collected 100,000's of stack traces, but only symbolically resolved 10's of them. Thus the gathering of the 100,000's of traces had to be very very efficient (only the return addresses being saved) but the symbolic resolution did not have to be so fast. This also solved the issue of working within signals which I also had to do, indeed the code had been used to arguably work at an even lower level than signal handlers -- but more on that would get off topic. I think that the interface needs to reflect this. Or at a minimum clearly state that symbol resolution will be delayed until absolutely necessary -- I think that it is best if the interface reflects this. In addition to my own code, the company I currently work for has a multi-platform stack trace library which also defers symbols resolution. Also until the symbols are resolved I think that the space requirement for a frame should be kept to the minimum (i.e. one pointer). This may necessitate two classes e.g. raw_stacktrace and symbolic_stacktrace with a means to convert between them, the symbolic_stacktrace should be all that is needed by default i.e. for most simple case users, potentially that means that having stacktrace and raw_stacktrace is better (raw_stacktrace only having a single pointer for each raw_frame). 2) Tracing optimized code on some architectures can be really quite difficult. Especially when there are performance constraints (for example on Microsoft x86 should FPO information be loaded, should the whole .pdb file be loaded to walk the stack). So I would suggest a user specified function could be used to provide some choice in the algorithm for how walk the stack back, with some default. 3) Modules / libraries. Something else I have found useful is the ability to examine a frame and find out the code module e.g. a .dll or .so from it. That then raises the possibility of another object in addition to stacktrace and frame. Members that I have found useful on a module object are things like path, load address, length (maybe begin/end for the address in memory), name, version, copyright notice (this can get rather platform specific). A boost::stacktrace is definitely needed. I'm hoping that we'll get one that can meet more than the simple case needs. - Mark -- View this message in context: http://boost.2283326.n4.nabble.com/stacktrace-review-tp4690649p4692111.html Sent from the Boost - Dev mailing list archive at Nabble.com.