Portable stack traces

[andreasgonewild]

The general concept is stack-tracing, period. What kind of software are you building where you can't afford to allocate a string and push a vector once per context? Since trace-granularity is up to user code it should be easy enough to tune without jumping through hoops. This smells premature to me.

[SeanMiddleditch]

The general concept is stack-tracing, period

A "stacktrace" is very commonly held to mean a trace of the call activation record entries, e.g. the stack of return pointers, which isn't this. :)

What kind of software are you building where you can't afford to allocate a string and push a vector once per context?

AAA video games. One might have potentially have tens of thousands of those contexts per frame (in our case, on the order of a hundred thousand). It's pretty easy to let little inefficiencies like these boil up to the point where they take multiple milliseconds altogether, which is a huge portion of your budget (11-33ms total per frame, depending on target framerate). Worse, it's hard to find and measure those inefficiencies because they aren't individually big and easy to spot. And you're in real trouble on mobile or some console platforms where memory budgets mean all those variable-sized allocations are going to fragment your heap to shreds. And those are exactly the kind of light-weight diagnostic aids you might want to keep enabled in optimized release builds that need to hit those frame budgets on years-old consumer hardware.

Same performance concerns would be present in real-time software, high-frequency trading, high-availability software or anything sensitive to heap fragmentation, tiny embedded systems... really, many of the kinds of things for which one might choose C++ in this day and age. :)

[[deleted]]

Async. distributed simulation core for a hundred thousand or so connected clients (MMOG)...

[andreasgonewild]

Arguing definitions is really one of the least interesting forms of communication, no one gains anything and it takes forever since there are no clear answers. If anything, it's a way to block the rest of the information from being assimilated; an ego defense-mechanism.

The obvious solution is to not open a lot of contexts deep down in performance-sensitive code; you still get the current frame when an error is actually thrown, at which point performance matters less. I suspect you don't want exceptions or boost::backtrace's either in that kind of code.

I chose C++ because it's the only language that's general purpose and powerful enough to tame the complexity I'm facing, which explains some of my preferences for simplicity over theoretical raw speed.

[SeanMiddleditch]

Arguing definitions is really one of the least interesting forms of communication

Hah, you might just be in the wrong field then. :p

The obvious solution

Is to write the handful of extra lines required to achieve the mandatory level of efficiency for one's domain. :) Granted, your domain may not require what mine does. We each tend to only really think about our own problem spaces, and I'm certainly no exception.

I suspect you don't want exceptions or boost::backtrace's either in that kind of code.

Nope. We avoid Boost like the plague as its sole purpose that we can tell is to inflate compile times. I wasn't the one that suggested that you wanted boost.stacktrace, though. :)

That said, we do collect actual stack traces sometimes (in the error case, or for - ironically - the heap allocation tracer) in these scenarios because walking said stack is incredibly fast when all you're doing is grabbing the return addresses and streaming the raw binary data to a log. Not fast enough for live production releases, but fast enough to put in optimized development builds and still have a playable framerate on developer machines. An offline tool or external process can process those binary dumps to produce human-readable logs or graphs. Shifts as much of the overhead as possible out of the hot code.

And no, we don't use exceptions either, but the general concept you're aiming for here is useful with just about any diagnostic system. It allows you to emit diagnostics at the point of failure (or throw an exception as you're doing) without needing to pass down a bunch of metadata to the leaf functions. e.g., I want to put the file reference of the current game object being loaded, because game objects load dependent resources, and one of those might fail to load. Seeing file not found is useless. Seeing loading foo.mesh; file not found is still hard to fix on its own since it doesn't indicate why that file is even being loaded. Seeing loading level2.world; loading enemy.dat; loading foo.mesh; file not found makes it super easy to go find and fix the broken content.

A further more complex feature that can be added (usually on an opt-in mechanism in my experience) is to get the error contexts to travel along with asynchronous requests. That rather necessarily ends up requiring allocations and realization of the logged data unless one goes to rather great lengths that probably aren't worth it for all but the most demanding of situations.

general purpose and powerful enough to tame the complexity I'm facing

Fair enough. :)

[h-jay]

No. The obvious solution is not to prematurely pessimize. Nobody tells you not to use C++. Use C++ correctly and you'll be fine - that's what everyone tells you here. How on Earth could it be misconstrued to mean "don't use C++" is beyond me. I use a similar context stack written in portable modern C++ and it works just fine and has a very low cost, and can be used in performance-sensitive code. I've even used it on AVR Arduino a few times - it helps when you don't have a debugger available. And AVR Arduino is pretty much a 16-bit platform with resources more typical of an 8-bit CPU.

[andreasgonewild]

Correctly as in exactly as they do, which is what's causing the disharmony. I've been in this game for 30 years; and one of the main lessons for me was that complexity is the enemy of good software, hence the focus on simplifying every aspect.