Then you need to practice believing more things.
I try to keep an open mind, but not so open my brains fall out...remember,
we actually have a claim on this thread that moving a single character one
space forward can take "a billion" cycles (perhaps Carl Sagan's ghost is
posting here contributing to the pointless obfuscatory pedantry)...
On some systems, a call to memmove() will generate an actual call to a
library function that moves one byte at a time just like your loop, and
thus will always be slower.
OK, we're STILL not up to a "billion" cycles, and I specifically covered
this possibility later in this post. All you're really doing here is
agreeing
with my post (remember, I'm the guy who doesn't want to call memmove()
at all except for large amounts of text). Unfortunately, what you write
is just technical "common sense", and thus is completely inappropriate
for THIS forum, in which there are imaginary "systems" that require a
"billion" cycles to move a single character one space forward...try to
conform to the "rules of the newsgroup", or face the most dire of
consequences...
On other systems, a call to memmove() will generate an actual call to a
library function that uses a few (maybe even just one) machine
instructions to move the bytes much faster than your byte at a time
loop. Which is faster depends on the number of bytes moved, how much
overhead there is in a function call, and how much faster the machine
instructions are than your loop. It is likely that your loop will be
faster for "short" strings and slower for "long" strings, but exactly
where the break-even point is will vary from system to system. It might
be just a few bytes, it might be tens of bytes, it might even be
hundreds of bytes (although probably not).
OK, I warned you about "common sense", and then you post a
whole bunch more of it...
On still other systems, a call to memmove() will generate those few (or
maybe even just one) machine instructions inline, which will almost
certainly be faster than your byte at a time loop all the time.
Does my turning off ALL optimizations factor into this? I think it
does, since the documentation specifically mentions inlining "intrinsic"
functions as one of the configurable optimization, and I'm pretty
sure memmove() is one of them...
Although the C standard describes fread()/fwrite() as working as if they
called fgetc()/fputc() for each byte, I've never seen an implementation
where they actually do that; real implementations nearly always *do* do
something special instead. On the other hand, I've seen actual
implementations use all three of the above methods of implementing
memmove().
OK, I actually use fread() and fwrite() anyway, so I guess I have
wasted any precious cycles THAT way...