This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Optimzed vs. readable code


On Nov 29, 2005, at 8:48 AM, Pierre THIERRY wrote:

Hi,

I just noted that the convention for the algorithms I have read in the
GNU STL, when using a starting and ending iterator between which one
want to move, seems to be to increment the first iterator.

We have things like this:

++first;

And tests like this:

*first == something

Semantically, that doesn't seem very nice. One can eventually get used to
it, when one knows, but wouldn't it be more judicious for the code to
become more readable, by adding:


current = first;

Thus, we get:

++current;

*current == something

I suppose using the (rather ugly) 'first' as moving iterator has a goal
of optimization, but any decent compiler is now able to optimize this (a
variable initialized with another who is never accessed anymore, locally
to a function), so that this change in the code indeed makes no
difference the the compiled result.


So would a patch with this kind of change be accepted?

You are the victim of unfortunate timing. :-) I just posted in another thread:


That philosophy is basically: Keep things as simple as possible. Don't gratuitously add code just to see if the compiler can optimize it back out.

(sorry :-) )


I think what you suggest is a valuable refactoring in some contexts. Very readable code is a real asset. That being said, libstdc++ is (or should be) an industrial strength, highly optimized library targeted for use in a great many applications world wide. I think in this context, readability is very important, but must take a back seat to performance (be it size of speed). And while you are probably correct that an optimizer will result in identical object code for changes like this, such a change is adding to the complexity of the overall product (library + compiler). More parts must work right in order to deliver the end-product: a small/fast algorithm.

I have been known to make decisions regarding readability in favor of better readability sometimes. But in this case I feel that the benefits do not outweigh the risks.

Just my .02 of course. I am not in a position to accept or reject your change.

-Howard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]