The last 20 years of experience have told me that that's the #1 variable that correlates with the death of a project, so I'm in no hurry to speed that along. People have been trying to find some way to skip that difficult step of actually understanding what's happened since programming was invented, and its always a bad idea - because that process of internalising a projects structure is the single most valuable thing for a project. Creating a project structure that can be internalised by human beings - and then doing that - is software engineering

There's no difference between the flag being set/unset by your build system, and #define-ing or #undef-ing the symbol in code

If you want to use asserts, you need to control the definition of NDEBUG. You either do this with your build system (common), or manually (slightly less common). This is literally 101

The preprocessor is widely used for a variety of things when its necessary, including #includes and #defines, because there's literally no other mechanism for this. Its bizarre to say that nobody controls the definition status of NDEBUG because people don't use the preprocessor

Its trivially easy to guarantee that an assert always runs, and its well defined behaviour according to the spec. There's no reason not to if you want to use asserts in a way that guarantees that they always fire, which is a supported use case. Its common practice

There's no equivalent for contracts

The programming model for C++ contracts as described by the authors, and spec, is that they are 'ghost code'. You must never assume that a contract check is actually executed, even if you've asked your compiler to execute your contract checks. This is because ABI/ODR problems can and will cause your contract checks to be deleted, as well as the 'observe' contract mode which is a strange one

So its hard to know what the use case for them is as a result. You can't use them for safety checks, because you must assume they won't be run. Hilariously, they actually introduce safety problems vs asset: Eg take two pieces of code:

    assert(p != nullptr);

    assert(p->some_value());

    contract_assert(p != nullptr);

    contract_assert(p->some_value());

I have a feeling that in 10 years the advice will be to never use contracts in anything approaching code that needs safety, as they're generally less safe than using an assert for no real reason. So what's their use case?

Valve rightly get a lot of flak for the gambling and high % cut, but you do get a functional useful service in return at least, that doesn't appear to be actively trying to screw you over

Its kind of appalling that people think this is an acceptable way to behave

The reason why 'reverse engineering' has gotten so good is because what we're actually seeing is fully automated luxury plagiarism

Bugs usually include business logic edge cases, and significant problems include someone realising while reading the PR that we can actually create a much better solution to the underlying problem. Ideally that realisation would happen prior to the PR being offered, but that's also not really how humans work

Example: During a PR review for a graphical feature for a game, someone reading it realises that we can actually have a significantly better solution to the underlying problem. You can't catch this in testing, because it doesn't even make sense conceptually to test it. It also sucks that it happened after someone put in a lot of work, but with graphics development you expect a lot of what you write to get canned and replaced with a better solution, because the technology evolves over time. The work is iterative towards the final goal anyway

Its also very common to miss subtle edge cases with graphics hardware, eg someone misunderstood the intricacies of GPU hardware, or a team member has relevant experience that someone else does not have. Or they missed a problematic memory access pattern on some hardware for example. Or something simple like they've technically forgotten a barrier, that the validation layer doesn't report for some reason

Eg: The function "tanh" is broken on some AMD GPU hardware, and should never be used under any circumstances. The actual GPU implementation of it is just screwed. Ideally everyone would know this, but its a very common function to crop up during specific graphics algorithms (as it smoothly remaps the range [-inf, +inf] -> [-1, 1]). So occasionally I've spotted that, and had to explain that we need to use an approximation instead, and then now everyone knows . It rarely gets caught during testing setups, because people don't know they need to include that hardware in their tests in the first place