Optimzed vs. readable code

[Pierre THIERRY]

Scribit Jonathan Wakely dies 30/11/2005 hora 17:18:
> If the change was to be accepted, should it be a new iterator object
> or just a reference to give the existing object a new name?

Now that I have thought of it (see my another post), I think the right
thing would be a reference. I'd let others do the choice, because I'm
not used to references much...

> Will the right choice still be the right choice in a year, when GCC's
> optimisers are different?  Or in five years?

I really can't see any compelling reason for a compiler to drop such a
simple and efficient optimization (it has no drawbacks, no side-effect,
etc.). But I'm no compiler guru.

> Who will keep measuring it to ensure the code is still optimal?

How do you keep measuring things to ensure the code is still optimal in
other locations of libstdc++'s code? I'm pretty sure the same method
would apply here.

> Your suggestion will probably never result in *better* code, so the
> best we can hope for is equal performance,

It *is* meant to provide exactly equal performance.

> but possibly worse if a regression occurs in the compiler

We have to let compilers' developpers deal with that. Are you telling
you will never adapt your coding techniques to the evolution of computer
science?

<flame>

Why don't you write libstdc++ in assembly, it wouldn't depend on any
compiler...

</flame>

> The primary use of the library code is not to be read by end users,
> it's to execute efficiently and correctly. It is executed many more
> times than it is read.

Do you know a reasonably used library that is more read than it is
executed?

> There are *far* harder things to understand in the code than a
> variable name that is misleading the first few times you see it  :-)

I agree with that. But I think the probability of regressions are so
close to zero and the benefit in the readability of libstdc++ so
immediate that it is worth. YMMV

Simply,
Nowhere man
-- 
nowhere.man@levallois.eu.org
OpenPGP 0xD9D50D8A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20051130/af1a5a85/attachment.sig>