suppose we have the following type:
typedef struct {
int bar;
int baz;
int foo;
} Something;
In order to do a copy, I usually do something like:
Something a, b;
...
memcpy ((void *) &a, (const void *) &b, sizeof(Something));
But also the following is legal (and far more quick to write).
Something a, b;
...
a = b;
Is there any disadvantage in doing the second one?
Name:
Anonymous2010-07-28 15:00
>>35 void (*mymemcpy)(void *, const void *, size_t) = &memcpy; and then use mymemcpy instead of memcpy.
>>35,40 I can't come up with some scheme to make GCC handle memcpy and = differently I want it to use the builtin memcpy, otherwise it's pointless.
Are you listening to yourself? Have you not read a single thing anyone else is saying? They're the same goddamn thing. The built-in memcpy() is not even a real function call. They can't behave differently because by definition they do the same thing.
>>46 They can't behave differently because by definition they do the same thing.
Correct, I looked that up in the source code for GCC (>>43). I had expected memcpy to be transformed into an assignment, but it was the other way around.
Name:
Anonymous2010-07-28 20:02
>>48
Well duh it's the other way around. All assignments can be transformed into memcpy, but not all memcpy can be transformed into assignments.
Name:
Anonymous2010-07-28 20:04
>>49
Erm, well excuse me. Meant to say "struct assignments". Obviously FP->integer assignments and such can't be turned into memcpy.