3 ms·
It's not that simple, because of inlining and macros. Those optimizations can be used to quickly throw out unnecessary code like null-pointer checks inside inl
by nhaehnle 12y ago
It's not that simple, because of inlining and macros.
Those optimizations can be used to quickly throw out unnecessary code like null-pointer checks inside inlined functions, so they are valuable and good to have.
So it's a matter of how much energy you spend on diagnostics, which ends up a rather heuristic field and perhaps we'd just be better off focusing on better static analysis tools that are separate from or can otherwise be decoupled from compilers.
- TheLoneWolfling 12y agoOne could at least throw an error / warning in "obvious" cases, like this.
- barrkel 12y agoAre we better served by fast and correct code, or faster and wrong? The gain from application of an optimization needs to be compared with the time and cost of bugs introduced by the same optimization. And dead code elimination isn't necessarily a huge win - if you're fairly sure code is dead, you can make it cheap at the cost of being more expensive should it actually be alive (see my other comment).
- kryptiskt 12y agoUnnecessary code is one thing, exploiting the presence of undefined behavior to compile something that the programmer likely didn't want is another. It doesn't matter much if it's fast if it's wrong. A good compiler shouldn't try to read the mind of the programmer, it should complain loudly and stop. It should be free to do so, given tha leeway it has with undefined behavior. And of course, the standards committee should get off their asses and define some behaviors.