Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.lang.misc Subject: Re: 100 Things Date: Thu, 01 May 2014 11:03:31 +1200 Lines: 25 Message-ID: References: <3SQ7v.155346$AI5.24849@fx32.am4> <85e8v.227832$gV7.159905@fx21.am4> <20140430150416.549@kylheku.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net b1YYeBMoV4Vms9jLCMuKPwNbXdz3iQuk5ixNO1WE5hzEQtpinl Cancel-Lock: sha1:Veiprxeqr2iaKzBqHUVJm7PSX4U= User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: Xref: csiph.com comp.lang.misc:2086 BartC wrote: > "Kaz Kylheku" wrote: >> >> Since strlen is a standard C function, the compiler can know that it has >> no side effects, and that it can be hoisted out of the loop if the loop >> doesn't alter the variable s, and doesn't potentially modify any memory >> that could be inside s. > > But in the absence of optimisation, or if the compiler can't determine what > happens to s, the expectation seems to be that the terminating expression is > calculated repeatedly. > > That's what I used to do, but now I calculate any such expression just once, > whether it can change or not. That's a slightly saner way of doing things as > the maximum loop iterations are known in advance. (That probably suits a > simpler iteration statement better than C's more open-ended one.) > > (It also gives the compiler I'm working on now its first performance edge > over gcc: Comparing performance without optimisation (or regards to correctness!) is pointless. -- Ian Collins