-> #include 
-> #include 
-> int main(void)
-> {
->         char *string = "this is a string";
->         printf("length is %d, stdlib is
%d\n",lenstr(string),strlen(string));
->         return output(string);
-> }
-> int lenstr(char *s)
-> {
->         int n=0;
->         while(*s++) n++;
->         return n;
-> }
   Writing your own String Len routine isn't "Thinking outside the box",
its waisting programming energy.  Why do so other than demonstrating
programming pratice, because most compilers already have a very well
optimized code for doing so, and using the above code will not compile
optimized any better than the built in libraries (and often worse).

->  > Some people call this "thinking outside the box".

->     Not really - that's Jonathan Creek's game. :-) The two loops quoted have
-> completely different functions and ranges. The first is a simple count, the
-> second is a fairly standard K&R string output loop.

->  > However, we were intending to compare generic for()
->  > and while() loops, showing how the obvious solutions
->  > weren't always so obvious.

->     You were implying that a for(;;) loop is inherently clearer than a while()
-> loop. Without elision that is simply not true.
   And just how is a for loop clearer?  By the fact alone that
   a for loop somewhat "hides" the increment portion of the loop,
   one does not realize as easily what is going on, and therefore
   automatically fogs things up....

->     Your preferences aside, Darin, you didn't answer the question. Pre and
-> post-increments behave differently, and you cannot always use just one or the
-> other without risking gross obfuscation.
   Just as a programmer will tend to understand either WHILE or UNTIL
easier and will write their code using either of the two most often,
so will a programmer tend to use one of the two most often, and will
generally setup any loops automatically thinking with the method they
prefer....
--- Platinum Xpress/Win/Wildcat5! v3.0pr3