On Fri, 6 Jan 2012, Toby Thain wrote:
The long version isn't less efficient.
Actually, it is, or at least may be, depending on the compiler;
gcc compiles to the
same assembly, which is what I meant by "not less
efficient".
I expect most popular compilers would do the same.
First, THANK YOU, for taking the time to check that out.
If you will recall, I said, UNLESS THE COMPILER OPTIMIZES.
Replacing your^H^H^H^H MY code with something "equivalent", but presumably
"better" is called OPTIMIZATION, and that is what happened, and why the
code produced identical results.
In this case, it is a correct and appropriate optimization.
Sometimes it isn't. Some early optimizing compilers created
complications (not with THIS, but with polling loops, etc.). But, in this
case, the optimization is completely correct.
The reason that they produce the same code, IS because gcc did NOT compile
what was asked for. It "knew" that there was a better way (DWIM?) and
replaced the requested code with equivalent.
IFF you turn off optimization COMPLETELY, then the results are NOT
identical. (If your results ARE identical, then you did NOT turn off
optimization)
After my screw-ups with forgetting what were extensions, other languages,
odd copmpiler weirdities, and my own unrefreshed unreliable dynamic RAM, I
need to add disclaimers:
"MOST/MANY C compilers"
WILL permit you to ask for
strcpy(p+1,p); /* on MOST/MANY compilers that is NOT a way to insert a
charcter position! */
C is not a padded room - the foot guns are fully loaded with plenty of
rope.
--
Grumpy Ol' Fred cisin at
xenosoft.com