Hello Jasen!

Replying to a message of Jasen Betts to Neil Heller:

 NH>> that I would consider it only natural that any optimizing compiler
 NH>> would do what you did, only automatically.  Is this the case?  Or
 NH>> should I be concerned with optimizing manually - not trusting the
 NH>> compiler manufacturer?

 JB> The compiler doesn't understand strlen.

;-)  Most modern compilers probably do understand strlen.  For example, I
believe Pentiums have a single hardware instruction that performs the
strlen function much faster than software can emulate, so you'll end up
with something that looks like a function call becoming pure assembly
;->

 JB> the C copiler understands all the keywords processd the #defines etc
 JB> but all library functions are treated as black boxes.

Can be true - but the optimiser knows some library functions...

 JB> So. it can't know that it always returns the same value if given the
 JB> same string, and even if it did it has no easy way to tell if the for
 JB> loop will modify the string.

This all depends.  Sometimes it can, sometimes it can't.  It probably gets
it right in a completely different manner than the casual reader (e.g.,
person maintaining the code 6 months later) would, so it's often a wise
point to actually make the constness of the value explicit.

 JB> assuming that target and the string are unmodifieed in the body of the
 JB> loop: the above for...  is better written

 JB>  for( n=0; target[n]; n++ ) {

 JB> which is another way of saying.

 JB>  for (n=0; target[n] != '\0' ; n++) {

I prefer this one.  ;-)

 JB> and possibly even better re-written to use a char* instead

 JB>  for( s=target ; *s ; s++ ) {

Yes, I like this even more ;-)

Darin

---