4 ms·

> Sigh. Yes, but here on Planet Earth, a lot of legacy code was (irresponsibly) written under the assumption that the contemporary compilers wouldn't change the

> Sigh. Yes, but here on Planet Earth, a lot of legacy code was (irresponsibly) written under the assumption that the contemporary compilers wouldn't change their behavior in the future. Why aren't they using the old version of the compiler? Keep your unoptimized, ill-formed code if you want, while everyone else can benefit from the newest features. You can't have your cake and eat it too. Either you want to use the new stuff and you'll have to adapt your code, or you don't want the new stuff and you can keep using your code as is.

SomeoneFromCA 3y ago
No need to be this passive aggresive. There is no need to break old code compatibility, while adding features into the compiler; this is how Visual Studio C++ (and most certainly Intel C++) is and always was; no surprises and excellent code quality.
CamperBob2 3y ago
Keep your unoptimized, ill-formed code if you want, while everyone else can benefit from the newest features. Sadly, that's the dilemma many embedded developers eventually have to face. I'd personally like to use modern C++ features when working on a legacy codebase that I inherited. Even if I don't want or need that sort of thing, newer compilers are also better at flagging potential errors and UB (hence the article.) Overall, CPUs are much faster now, and memory is much cheaper. So I can afford to trade off a bit of overhead for better code quality and engineering discipline. And yes, newer compilers are also better at optimization, but that's literally the last thing I care about in the embedded business. I'm not targeting 8051s and 8-bit AVRs anymore. Unfortunately, what I can't afford is the time needed to review 200K+ LOCs to find all the hidden gotchas that will be exposed by newer, more aggressive compilers. There may be bugs that should have been fixed years ago, but that never surfaced. Some will trigger new warnings (again, hence the article) but will all of them be flagged? My whole point is that dealing with a broken build due to -Werror is so far down in the noise it's not even worth mentioning. If I fix the issues responsible for the new error messages and walk away thinking my job is done, well... maybe this is my lucky day, and maybe it isn't.

SomeoneFromCA 3y ago

No need to be this passive aggresive. There is no need to break old code compatibility, while adding features into the compiler; this is how Visual Studio C++ (and most certainly Intel C++) is and always was; no surprises and excellent code quality.

CamperBob2 3y ago

Keep your unoptimized, ill-formed code if you want, while everyone else can benefit from the newest features. Sadly, that's the dilemma many embedded developers eventually have to face. I'd personally like to use modern C++ features when working on a legacy codebase that I inherited. Even if I don't want or need that sort of thing, newer compilers are also better at flagging potential errors and UB (hence the article.) Overall, CPUs are much faster now, and memory is much cheaper. So I can afford to trade off a bit of overhead for better code quality and engineering discipline. And yes, newer compilers are also better at optimization, but that's literally the last thing I care about in the embedded business. I'm not targeting 8051s and 8-bit AVRs anymore. Unfortunately, what I can't afford is the time needed to review 200K+ LOCs to find all the hidden gotchas that will be exposed by newer, more aggressive compilers. There may be bugs that should have been fixed years ago, but that never surfaced. Some will trigger new warnings (again, hence the article) but will all of them be flagged? My whole point is that dealing with a broken build due to -Werror is so far down in the noise it's not even worth mentioning. If I fix the issues responsible for the new error messages and walk away thinking my job is done, well... maybe this is my lucky day, and maybe it isn't.