Questions about memmove

[Method Man]

Just a few theoretical questions I had on 'memmove':

1. Is there ever a good reason to use memcpy instead of memmove?
2. Is memmove useful to copy structs (as opposed to = operator)?
3. In general, when should memmove explicitly be used? [I have only seen it
used in code to copy char arrays and even then, <string.h> provides most of
the necessary functionality.]

[Thomas Matthews]

Method Man wrote:

Just a few theoretical questions I had on 'memmove':

1. Is there ever a good reason to use memcpy instead of memmove? Yes, when the source and destination do not overlap.
The memcpy function may be more efficient since it doesn't have
to be as careful as memmove.

2. Is memmove useful to copy structs (as opposed to = operator)? As long as the structs do not contain pointers or instances of
structures (which may contain pointers). With pointers, one
runs into ownership and duplication issues.

3. In general, when should memmove explicitly be used? [I have only seen it
used in code to copy char arrays and even then, <string.h> provides most of
the necessary functionality.]

The function memmove should explicity be used when the source and
destination locations overlap.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.l earn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

[Malcolm]

"Method Man" <a@b.c> wrote

1. Is there ever a good reason to use memcpy instead of memmove?
Yes, it makes your intentions clearer if memmove() is reserved for
potentially overlapping regions. Also it may be more efficient to call
memcpy().
2. Is memmove useful to copy structs (as opposed to = operator)?
Use memcpy() for this. Personally I dislike the = operator applied to struct
assignments, since it fails to make clear that this may be an expensive
operation. To people used to other languages, it also fails to make it
obvious that this is a "shallow copy".
3. In general, when should memmove explicitly be used? [I have only seen it used in code to copy char arrays and even then, <string.h> provides most of the necessary functionality.]

Let's say we have an array of objects, and we want to insert an item in the
middle. The items at the end are unused, because the array capacity is
bigger than the actual contents. By calling memove we can move all items up
by one, and then insert our entry.
Since this operation is expensive, it is not used all that often (if you
expect a lot of inserts, you would use a tree or a linked list instead). But
it is still useful on occasions.

[pete]

Method Man wrote:

Just a few theoretical questions I had on 'memmove':

1. Is there ever a good reason to use memcpy instead of memmove?
If you're copying between nonoverlapping regions of memory.
2. Is memmove useful to copy structs (as opposed to = operator)?
I prefer the assignment operator for stucture copying.
It gives the compiler an oportunity to accomplish the deed
whichever way is best.
If your structure has just a few int type members,
then a structure assignment,
might translate into just a few int assignment instructions.
3. In general, when should memmove explicitly be used?
[I have only seen it used in code to copy char arrays and even then,
<string.h> provides most of the necessary functionality.]

memmove is a string function. What do you mean by
"<string.h> provides most of the necessary functionality." ?

--
pete

[Keith Thompson]

pete <pf*****@mindsp ring.com> writes:

Method Man wrote:

[...]

3. In general, when should memmove explicitly be used?
[I have only seen it used in code to copy char arrays and even then,
<string.h> provides most of the necessary functionality.]

memmove is a string function. What do you mean by
"<string.h> provides most of the necessary functionality." ?

memmove isn't what I would call a string function, even though it's
declared in <string.h>. It operates on arrays of characters, not on
strings. (A string, by definition, is terminated by a nul character.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Keith Thompson wrote:

pete <pf*****@mindsp ring.com> writes:

Method Man wrote: [...]

3. In general, when should memmove explicitly be used?
[I have only seen it used in code to copy char arrays and even then,
<string.h> provides most of the necessary functionality.]

memmove is a string function. What do you mean by
"<string.h> provides most of the necessary functionality." ?

memmove isn't what I would call a string function,
even though it's declared in <string.h>.

I think that's sufficient to make it a string function.
Both char * and void * arguments are mentioned in the section
of the standard which is labeled "String function conventions".
void * arguments don't apply to any of the string functions
which take pointers to strings as arguments.
It operates on arrays of characters, not on strings.
(A string, by definition, is terminated by a nul character.)

--
pete

[Method Man]

> > 2. Is memmove useful to copy structs (as opposed to = operator)?

As long as the structs do not contain pointers or instances of
structures (which may contain pointers). With pointers, one
runs into ownership and duplication issues.

Could you elaborate on this point for me?

Since pointers are just addresses, I don't see why it would be a problem to
copy struct pointers over using 'memmove'. What are the ownership and
duplication issues? I can understand the copying issue with having an
instance of a struct within a struct.

In cases where structs contain a pointer or instance of another struct, what
_would_ happen if memmove was called?

[Method Man]

> memmove is a string function. What do you mean by

"<string.h> provides most of the necessary functionality." ?

For example, using strcpy or strncpy vs. using memmove to copy char arrays.

[Malcolm]

"Method Man" <a@b.c> wrote in message

Since pointers are just addresses, I don't see why it would be a problem to copy struct pointers over using 'memmove'. What are the ownership and
duplication issues? I can understand the copying issue with having an
instance of a struct within a struct.

(Untested)

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef struct
{
char *name;
} EMPLOYEE;

EMPLOYEE *employee(const char *name);
void killemployee(EM PLOYEE *emp);
int main(void)
{
EMPLOYEE *emp;
EMPLOYEE *copy;

emp = employee("Fred Bloggs");
copy = employee("Bill Gates");

if(!emp || ! copy)
exit(EXIT_FAILU RE);

memmove(copy, emp, sizeof(EMPLOYEE ));

killemployee(em p);

printf("Employe e left = %s\n", copy->name);

killemployee(co py);

return 0;

}

EMPLOYEE *employee(const char *name)
{
EMPLOYEE *answer;

answer = malloc(sizeof(E MPLOYEE));
if(answer)
{
answer->name = malloc( strlen(name) + 1);
if(!answer->name)
{
free(answer);
return 0;
}
strcpy(answer>n ame, name));
}

return answer;
}

void killemployee(EM PLOYEE *emp)
{
emp->name[0] = 'X'; /* shred garbage */
free(emp->name);
free(emp);
}

[James Dow Allen]

"Malcolm" <ma*****@55bank .freeserve.co.u k> wrote in message news:<cj******* ***@news6.svr.p ol.co.uk>...

"Method Man" <a@b.c> wrote

2. Is memmove useful to copy structs (as opposed to = operator)?

Use memcpy() for this. Personally I dislike the = operator applied to struct
assignments, since it fails to make clear that this may be an expensive
operation. To people used to other languages, it also fails to make it
obvious that this is a "shallow copy".

Yes (though another reason to call attention to structure copy besides
its possible expense, is that it may "alter data in a significant way"
that "=" usually doesn't).

Long long ago, my program failed to read consecutive disk sectors without
"slipping a rev"; there was a lot of cache-checking code, etc. but the
culprit was just an innocuous-looking " sector %= secs_per_trk; "
Obviously I would have noticed and fixed this computational bottleneck
much sooner if the / and % operators were replaced with
"do_a_time_cons uming_divide()"

James