• Welcome to Valhalla Legends Archive.
 

[C++] Question about memmove()

Started by Sorc.Polgara, December 14, 2005, 10:22 AM

Previous topic - Next topic

Sorc.Polgara

Ok, is the memory block that memmove() moves deallocated or is the moved memory block still allocated in it's original location?

It doesn't seem to say in the documentation.

MyndFyre

It seems like it would not.  memmove() describes itself as correctly overwriting the destination memory even if the source memory overlaps it.

Also, *src is marked const.  That should tell you right there.  The pointer is not changed.  :p
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Sorc.Polgara

Quote from: MyndFyre on December 14, 2005, 11:05 AM
It seems like it would not.  memmove() describes itself as correctly overwriting the destination memory even if the source memory overlaps it.

Also, *src is marked const.  That should tell you right there.  The pointer is not changed.  :p
Aight, thanks.  I'm nub.

Kp

Just to clarify, memmove() and memcpy() are about copying the values in the memory.  They don't know or care how the memory is allocated.  It could be backed by the stack, the heap, or a memory mapped file.  They're really just smarter versions of the following loop:


for (i = 0; i < end; ++i)
    dest[i] = src[i];


They're smarter in that they can do block copies (not byte-sized), if appropriate.  memmove is also documented to know when running the loop as written will cause undesired output.  Consider if dest = src + (end / 2).  Then the second half of source is the first half of dest, so running my loop above would corrupt the output.  memmove will handle this case by using a different looping construct.  memcpy will not.  Thus, memcpy may be marginally faster since it doesn't do that extra safety check.

To reiterate my original point, neither knows anything about allocations, so it cannot move an allocation -- only the bytes inside that allocation.
[19:20:23] (BotNet) <[vL]Kp> Any idiot can make a bot with CSB, and many do!

Adron

Particularly, memcpy is likely to be unrolled into some mov's if you do it on a small buffer, while memmove mostly will not.