I ask them how much money they've lost on C/C++ buffer overflows in the past, and how much they're willing to lose on them in the future :-)

Heartbleed. A C buffer overflow bug so disastrously expensive it has it's own logo!

(I know C# doesn't have buffer overflows either, but C# is a much bigger change than going to D, and is less portable.)

Valid point, buffer-overflows can be disastrous and should be easily preventable, or impossible, in a sensible language.

For OpenMW though, it's not a concern. They're building a single-player video game; the input is always trusted. As far as I can see, they made the right call by moving to C++.

Again, I really like the D language - but I can see why a project manager would go with C++.

TBF, c++ has std::vector and std::list.

And with the "usual" access '[]' std::vector doesn't bound check either, you have to use 'at' for this (except in some library with some flags ), doesn't seem that safe to me!

Agree. It strikes me as silly that C++ doesn't provide something like a `CHECKED` macro, so that operator[] could always be range-checked in debug/dev builds, but not in release builds. The two-different-methods approach seems awfully clunky - what ends up happening is that no-one uses the `at` method. I see no good reason not to enable range-checks by default in debug builds.

This 'unsafe by default' philosophy isn't universal in C++ though. The smart-pointer class-templates are always thread-safe, despite the possible performance consequences.