Tip #4: Take Advantage of Security and Correctness
The new compiler does two things:
- It’s much better at optimisation and will optimise as much as it can (great for performance)
- If there’s something unexpected that it might do, it will tell you.
#2 is critical. Compilers optimise heavily, and often rely on undefined behaviour, where code is not correct. It would be easy to think this could mean previously ‘working’ code might seem to stop working. Worrying, right? Right? No. That’s where #2 comes in because if you have a situation like that, the compiler will tell you.
It is not silent, and it communicates, and communicates well.
I blogged an example of this a few months ago where code used an uninitialized variable. That means that the code’s behaviour was unintentionally random, relying on whatever was in memory where that variable was located.
Info: Uninitialized variables are a great example of code you might think is working, but doesn’t. A boolean, which is uninitialized, will simply be true or false based on whatever was in memory wherever that variable was located. There’s a decent chance that for your program, for your test data, for your specific compiler and RTl version, that value will always be some value that evaluates as either true or false fairly consistently. Often it can be 99% of the time for years. So you won’t notice.
But it actually never worked. You just didn’t know.
The new toolchain knows it’s not valid to rely on the value of a variable that never had a value set. It also wants to optimise based on what the variable can be. So for code paths that are incorrect, it inserts a trap (a crash), meaning that it can guarantee if it gets past that, the optimisations is makes are correct. It all makes sense — it just can be unexpected. And the easy reaction is, ‘my code worked before and doesn’t now.’
Here’s the key: the compiler emits a warning and tells you. There should be zero surprise. It will tell you that there’s an issue. And you should be able to spot and fix it before you even finish compiling.
The point of this post? Take advantage of that.
Because these warnings catch genuine bugs you might not have known existed.
Compile with all warnings (-Wall, use this as minimum) or even more (-Wextra, some of these may be false positives though.)
What customers have seen
This is great to know because several customers have contacted us praising the new compiler’s warnings. They’ve told us things like,
‘Because of the new compiler, I fixed bugs that had been around for 20 years.’
That’s the kind of thing I like seeing from an upgrade! You can be one of those customers too.
How many bugs do you have which occur just one in a thousand times? Which go away when you compile in debug mode? Which your users report but you’ve never seen? Use the new toolchain. It will tell you. Then you can fix them.
Info: We have found issues because of this toolchain, too. This compiler finds issues other compilers, including other mainstream C++ Windows compilers, don’t. Everything it flagged in our codebase was real, and we fixed it. These warnings are valuable.
Of course, you can turn down optimisation, or turn on settings that prevent some of these optimisations. But it’s far better to use your tools. If something is wrong in your new code, you have a tool now that will tell you, directly and clearly. Take advantage of it.