On Mar 19, 2016 1:19 PM, "James K. Lowden" <jklowden at schemamania.org> wrote: > > On Sat, 19 Mar 2016 02:04:35 -0600 > Scott Robison <scott at casaderobison.com> wrote: > > > As he says, there's not real choice between fast and > > > correct > > > > Except that testing can verify something is correct for a given > > environment. > > That's actually not true, on a couple of levels.
True, and that was a sloppy phrasing on my part. Please replace "correct" with "sufficiently correct for the use case". If you are writing software for one environment you are in a very different situation than if you are trying to write truly portable software intended to be built and used in any arbitrary environment. > Second, you can't test the future. If the correctness of the code is > subject to change by the compiler's interpretation of the language, how > is the programmer to prevent it? In addition to DRH's comment about the moving target set by evolving standards: even if there was nothing undefined by the standard you can't trust a new release of a compiler or library to have not introduced some bug that impacts you. Hence the need to test the heck out of any intended release. It's not proof of correctness but it is evidence of a likely sufficiently correct program. > > > > finally drive gcc & friends in the direction of working > > > with their users for a change. Or make them irrelevant. > > > > I think they'd continue to be popular with people looking to eek out > > as much performance as possible. > > You may be right. As a consultant I've often felt I was hired to > sprinkle magic pixie performance dust on the system. People want to > believe that performance is found in tools. How come there's no -O5? > > In truth, every performance problem I've encountered was a design > problem, often obvious, always unnecessary. "Use a better compiler" > has never been the solution. Unloading mounds of unnecessary > processing with a pitchfork is. I guess it depends on what you're doing. Some applications (I'm thinking games at the moment) need both quality design and quality code generation. When you know your application is being targeted for a platform you'll utilize undefined behavior if it eeks out a little bit more performance. If necessary you'll hide UB in conditional blocks so that you get the best out of different platforms. I agree that most applications do not need anything like this, and I think it is a good idea to steer clear of UB, but it is not universally true.
