C++ version of memcpy?

[Samee Zahur]

Hi all,
I'm a little confused - my guess is memcpy is no longer (or perhaps
never was) a standard c++ function, since it has very little type check
into it - and can potentially create havoc for user-defined types. Now
my confusion is here - a simple instantiation of the standard copy
algorithm can be quite slow compared to the older memcpy for obvious
reasons - specially for a large array of built-in types like int or
something; so do the majority of the compilers optimise this into a
single memcpy when used with POD types? How about the popular ones like
g++ or VC6?

Or, if memcpy is still in the c++ standard, why is it so and in
which standard header file can we find it?

Samee

 

[Rolf Magnus]

Hi all,
I'm a little confused - my guess is memcpy is no longer (or perhaps
never was) a standard c++ function, since it has very little type check
into it - and can potentially create havoc for user-defined types. Now
my confusion is here - a simple instantiation of the standard copy
algorithm can be quite slow compared to the older memcpy for obvious
reasons

Did you measure that or is that speculation?

- specially for a large array of built-in types like int or
something; so do the majority of the compilers optimise this into a
single memcpy when used with POD types? How about the popular ones like
g++ or VC6?

You could look into the source code or measure it.

Or, if memcpy is still in the c++ standard, why is it so and in
which standard header file can we find it?

It is a standard C++ function, simply because the whole C standard library
was made part of the C++ standard library. It is declared in <cstring> (in
namespace std) and in <string.h>.

 

[ben]

memcpy is presented in <memory> under namespace std.

The reason why both memcpy and user-defined object copying mechanisms (copy
constructor, assignment operator, explicit function) exist in the standard,
is that they perform are two distinct tasks--to copy raw memory and to copy
objects. Although the latter usually makes use of the former, it is not
always the case. If you find code uses memcpy to deal with objects, throw it
away! Likewise if you find code dealing with raw memory copying using
assignment in a for-loop, chances are high it is a suboptimal one.

 

[Ioannis Vranos]

memcpy is presented in <memory> under namespace std.

Actually <memory> defines allocators. memcpy() is defined in header <cstring> in the
namespace std, and <string.h> in the global namespace.

 

[Mark Stijnman]

Hi all,
I'm a little confused - my guess is memcpy is no longer (or perhaps
never was) a standard c++ function, since it has very little type check
into it - and can potentially create havoc for user-defined types. Now
my confusion is here - a simple instantiation of the standard copy
algorithm can be quite slow compared to the older memcpy for obvious
reasons - specially for a large array of built-in types like int or
something; so do the majority of the compilers optimise this into a
single memcpy when used with POD types? How about the popular ones like
g++ or VC6?

Or, if memcpy is still in the c++ standard, why is it so and in
which standard header file can we find it?

Samee

From the gnu standard c++ library documentation for std::copy:

"This inline function will boil down to a call to memmove whenever
possible. Failing that, if random access iterators are passed, then the
loop count will be known (and therefore a candidate for compiler
optimizations such as unrolling). Result may not be contained within
[first,last); the copy_backward function should be used instead."

So there should be no real reason not to use std::copy.

grtz Mark

 

[ben]

Sorry! My mistake! memcpy is indeed in <cstring>

ben

 

[Marcin Kaliciñski]

Likewise if you find code dealing with raw memory copying using

assignment in a for-loop, chances are high it is a suboptimal one

You may be wrong with this one. The following functions f and g:

void f(int *a, int *b, int n)
{
for (int i = 0; i < n; ++i)
a = b;
}

void g(int *a, int *b, int n)
{
memcpy(a, b, sizeof(int) * n);
}

generate exactly the same machine code, under VC6, VC7, VC7.1 and also
probably under VC8. I don't know about gcc, but I suppose it also does that.

cheers,
M.

 

[block111]

never was) a standard c++ function, since it has very little type
check

into it - and can potentially create havoc for user-defined types.

Now

what sort of type check do you want for a function to be able to do to
copy memory? I think it's clear and completely right that a function
that copies memory from one place to another takes two addresses and
size of the memory area. There's nothing else needed. The problem is
that if you copy your own object using this function you can mess up if
you don't know what you're doing and it's not memcpy's fault in that
case - you don't copy your objects you only copy memory allocated for
them.

generate exactly the same machine code, under VC6, VC7, VC7.1 and also
probably under VC8. I don't know about gcc, but I suppose it also

does that.

It's a matter of a particular implementation. Other compilers/libraries
may provide a different implementation for memcpy and in case if you
copy around megs of data in your application it would be much more
efficient to use mmx/sse/sse2 for this task. Simply ms compiler (g++
and others) provide a simple implementation where it just copies memory
byte by byte since memcpy is mostly used with short c strings I think...

 

[Samee Zahur]

generate exactly the same machine code, under VC6, VC7, VC7.1 and also
probably under VC8. I don't know about gcc, but I suppose it also does that.

cheers,
M.

Seriously??? I didn't check the assembler listings output, but I never
expected these optimizations to be THIS common ... I suppose, compilers
do this for just about every POD datatypes and not just built-in ones?

Samee