Re: Inherent inefficiency in domestic "for" loop?
- From: gordonb.mw6ol@xxxxxxxxxxx (Gordon Burditt)
- Date: Mon, 26 Jun 2006 00:39:36 -0000
A for loop is *supposed* to, under
the right conditions, execute 0 iterations.
Yes, exactly. But about 90% of the time, we're dealing with a loop which
will always execute at least once. For this 90% of the time, there's one
extra redudant evaluation performed.
Unless the compiler unrolls it. And you haven't demonstrated that
performing the extra redundant evaluation isn't faster. And it is
possible for the compiler to generate code that skips the redundant
comparison if it can determine that it is redundant.
If you want a do while loop, you known where to find it.
I don't think the "for" loop should have been shaped to accomodate the 10%
of the time where we might not want the loop to run at all.
In other words: speed trumps all, incorrectness 10% of the time
is unimportant. And if correctness is unimportant, anything can
run in 0 time and 0 bytes.
there should have been another kind of loop availabe, analogous as to how a
"while loop" has a sister "do loop".
Why is this worthwhile? Assuming such a loop WAS available, why
should I spend 1,000,000 comparisons in CPU time re-compiling a
program in order to save one comparison?
Even something like a "do for" loop would be nice:
do for( i = 0; i != some_value; ++i)
/* Body */
The first time someone has to debug using a do for () instead of a for(),
you'll probably use up 100 years of savings from that redundant comparison.
Gordon L. Burditt
- Prev by Date: Re: Inherent inefficiency in domestic "for" loop?
- Next by Date: Re: beginner c question
- Previous by thread: Re: Inherent inefficiency in domestic "for" loop?
- Next by thread: Re: Inherent inefficiency in domestic "for" loop?