Hacker News Reader

Comment by Chaosvex | Hacker News Reader

Saying it doesn't even do bounds checking (in release builds) is to miss one of the major points of C++ - not paying for what you don't need. It's not a mistake, it's a feature.

You complain about it not being suitable for game development in one comment but then expect bounds checking in release builds? You're sitting in multiple lanes at the same time.

NIH implementations are usually grossly inferior because as it turns out, it's quite hard to get it right and those edge-cases aren't important until you start getting bitten by them when you'd rather be shipping features.

View on HN

> bounds checking in release builds

Bounds checking overhead is negligible for all but the absolutely hottest code paths (fwiw we shipped active asserts, including bounds checking asserts in all the PC games I was involved with - carefully monitoring the overhead of course).

The main reason to not use the stdlib isn't so much about squeezing out the last bit of performance, but about control of what actually happens under the hood (and also compilation times). The overall runtime cost of all those active asserts (not just the range checks, everything) was somewhere in the 2..3% range, which is fine when budgeted for upfront.

That's your opinion, others won't agree and would much rather not pay the price at all.

Those asserts probably saved a lot of development costs and increased the robustness of the software, which is worth a lot more than a few percent on a benchmark.

I personally am more conservative on those things. I'll pick the fastest thing that is reliable.

Are we talking about games or medical devices here? I expect different things from them. If a medical device needs to turn off bounds checking to get results I'm concerned enough to not want to let anyone use it. If a game can get a slight performance improvement I'm all for it, who cares if it crashes, it is just a game.

Who cares if it crashes? The users.

We can all agree it's not medical systems, but audio DSP and game dev both end up rewriting a lot of STL stuff to suit their needs, and often using a restricted subset of modern C++ features for similar reasons.

That isn't some arbitrary choice, but pretty much where everyone continually ends up when solving real-time problems using C++. Whether those be games or not.

You can prevent more than enough crashes with enough testing to make gamers happy. Even if you prove there is not out of bounds error I still want a medical device to check

Even with an extreme high level of inhouse testing (which is needed anyway) you'll never find the bugs that are discovered when a hundred-thousand gamers try to exploit every little feature of your game.

The reason to keep asserts in release mode is so that when one of those asserts is triggered "out in the wild" the bug investigation is dramatically simplified. The assert message and callstack is usually enough to figure out what went wrong. With a regular crash that happens without asserts the actual reason of the crash may already be obfuscated enough that a useful bug diagnosis is no longer possible. E.g. an assert is usually triggered very close to the bug, while crashes are usually only the end result of a whole cascade of events triggered by an initial bug.

Fair, but the counter is eventually you have enough real world testing to have confidence and so you no longer need the assert. If 1 in 10 user's have a crash that is unacceptable. However, what if it's only one in a million, or one in ten billion? At what point can you say, 'it's no longer worth worrying about that rare case.'

And this is why games are different from medical devices. In medical devices, I would worry anyway. In games, especially in a tight loop, it may be that extra CPU instruction is an important difference in performance.

Screw this game! I lost all of my progress because it crashed and the last auto-save is 10 minutes old. Uninstalled. 0 stars. Getting a refund.

The point is that STL does make you pay for stuff you don't need. In complexity and compile times. There's reasons Jai is being developed, and they're not all that Jonathon Blow is weird. As much as C++ owns the game industry right now, it has observable deficits as a great game programming language.

Sometimes there are ways of getting runtime bounds checking.

For example, both of these return the 3rd element of a std::vector:

    auto val1 = vec[3];     // no bounds checking
    auto val2 = vec.at(3);  // bounds checking

Yes, with the trade-off of essentially requiring exceptions, which are also banned in some codebases.

Reply on news.ycombinator.com