memcpy for copying arrays

F

franky.backeljauw

Hello,

following my question on "std::copy versus pointer copy versus member
copy", I had some doubts on the function memcpy, as was used by tom_usenet
in his reply.

- Is this a c++ standard library function? That is, can I be sure that
every c++ standard library has this function? Or is there a c++
alternative to it?

- How does this function work?

- Can this function be used to copy arrays of e.g. ints, long doubles,
.... safely?

- What else should I know about this function?

Thanks for any reply.

Regards,

Franky B.
 
A

Attila Feher

Hello,

following my question on "std::copy versus pointer copy versus member
copy", I had some doubts on the function memcpy, as was used by
tom_usenet in his reply.

- Is this a c++ standard library function?

It is.
That is, can I be sure
that every c++ standard library has this function?
Yes.

Or is there a c++ alternative to it?
std::copy.

- How does this function work?

Implementation defined.
- Can this function be used to copy arrays of e.g. ints, long doubles,
... safely?

It can be used to copy PODs safely.
- What else should I know about this function?

It is a C library function.
 
T

tom_usenet

Hello,

following my question on "std::copy versus pointer copy versus member
copy", I had some doubts on the function memcpy, as was used by tom_usenet
in his reply.

- Is this a c++ standard library function? That is, can I be sure that
every c++ standard library has this function? Or is there a c++
alternative to it?

It is standard in C and C++. std::memcpy is in the <cstring> header.
- How does this function work?

Depends on the implementation. Sometimes it is a compiler intrinsic
that causes appropriate inline assembler to be inserted. Sometimes it
is just a function that copies bytes in a loop. Sometimes it is a
function implemented in assembler.
- Can this function be used to copy arrays of e.g. ints, long doubles,
... safely?

You can copy any POD types with it (including built ins).
- What else should I know about this function?

The source and destination ranges cannot overlap. If they might
overlap, use memmove instead (which is usually a bit slower).

Tom
 
F

franky.backeljauw

It is standard in C and C++. std::memcpy is in the <cstring> header.
It is also present as ::memcpy, in the <string.h> header. std::copy
could be considered an alternative, but memcpy is still part of C++.

What do you mean by "is still part of C++"? And in what sense is
std::copy an alternative (being so much slower, given the results of our
earlier tests)?
Depends on the implementation. Sometimes it is a compiler intrinsic
that causes appropriate inline assembler to be inserted. Sometimes it
is just a function that copies bytes in a loop. Sometimes it is a
function implemented in assembler.

But it can be considered as the most optimal available function to copy
arrays?
You can copy any POD types with it (including built ins).

And how is this done? E.g. how do I copy an array of doubles?
The source and destination ranges cannot overlap. If they might
overlap, use memmove instead (which is usually a bit slower).

I think std::copy uses memmove (at least in gcc/libstdc++), but it is not
a bit slower, but a lot ...

Regards,

Franky B.
 
F

franky.backeljauw

It is.


std::copy.

But if it is a c++ function, then in which sense is std::copy an
alternative?
It is a C library function.

So I should use std::copy instead? Will memcpy, being a C library
function, always be available in C++?

Regards,

Franky B.
 
W

White Wolf

What do you mean by "is still part of C++"?

It means it is not removed from it, it comes with the C part.
And in what sense is
std::copy an alternative (being so much slower, given the results of
our earlier tests)?

One implementation you have seen was slower. In other implementations it
finds out you have a POD and translates to a pure call to memcopy or faster.
But it can be considered as the most optimal available function to
copy arrays?

No. In some systems memcopy is actually slower than a hand-made loop with a
Duff's device. A good C++ standard library implementation can take it into
account and make std::copy use a better algorithm.
And how is this done? E.g. how do I copy an array of doubles?

Look at your compilers documentation. Or use google.
I think std::copy uses memmove (at least in gcc/libstdc++), but it is
not a bit slower, but a lot ...

It might be, but that is an implementation issue.
 
K

Kevin Goodsell

But if it is a c++ function, then in which sense is std::copy an
alternative?

You have (at least) two options. In other words, two alternatives. One
is an alternative to the other.
So I should use std::copy instead? Will memcpy, being a C library
function, always be available in C++?

You can use whatever you feel is appropriate (but of course memcpy is
not appropriate for non-POD types). memcpy, being a C standard library
function, is therefore part of the C++ standard library, and provided
with all standard C++ implementations.

-Kevin
 
W

White Wolf

But if it is a c++ function, then in which sense is std::copy an
alternative?

In the sense that it can be used in its place (and must be used with
non-PODs).
So I should use std::copy instead?

It depends. If you are trying to copy non-PODs you must. If you copy
PODs - again - it depends. But iIMHO you should not worry about it too much
until it shows up that (you need something else (like on one of your
supported platforms memcpy is dead slow). If you use PODs and it seems you
will use PODs at that part of the code forever (like doubles) I see no
reason not to use memcpy. Unfortunately with todays C++ library
implementations (in widespread use) memcpy usually will be faster than
std::copy. it should not be this way, but it is.
Will memcpy, being a C library
function, always be available in C++?

I am no future teller, but I know about no intensions to remove it. And as
of today I have access to the C++ comitee documents - and I saw no proposal
to remove it. :) Sorry, it is funny. I believe that you can trust that as
long as C and C++ will be around memcpy will be a part of it.
 
F

franky.backeljauw

It depends. If you are trying to copy non-PODs you must. If you copy
PODs - again - it depends. But iIMHO you should not worry about it too much
until it shows up that (you need something else (like on one of your
supported platforms memcpy is dead slow). If you use PODs and it seems you
will use PODs at that part of the code forever (like doubles) I see no
reason not to use memcpy. Unfortunately with todays C++ library
implementations (in widespread use) memcpy usually will be faster than
std::copy. it should not be this way, but it is.

So I am not the only one to state that std::copy is slower than memcpy.
Indeed, it should not be this way ...
I am no future teller, but I know about no intensions to remove it. And as
of today I have access to the C++ comitee documents - and I saw no proposal
to remove it. :) Sorry, it is funny. I believe that you can trust that as
long as C and C++ will be around memcpy will be a part of it.

Okay, thanks for the information.

Regards,

Franky B.
 
T

tom_usenet

What do you mean by "is still part of C++"?

It was part of the C standard, and, along with the rest of the C
standard library (with minor changes), it became part of the C++
standard.

And in what sense is
std::copy an alternative (being so much slower, given the results of our
earlier tests)?

std::copy is a type-safe alternative to the non-typesafe function,
std::memcpy. In addition, std::copy works with overlapped source and
destination ranges, whilst memcpy doesn't, so, really, I suppose
std::copy is an alternative to std::memmove rather than memcpy.
But it can be considered as the most optimal available function to copy
arrays?

It should be, but it is a quality of implementation issue. It's up to
your compiler vendor and how much time they've spent tweaking it. You
might want to read this:

http://www.cuj.com/documents/s=7990/cujcexp1910alexandr/alexandr.htm
And how is this done? E.g. how do I copy an array of doubles?

double source[10] = {blah};
double dest[10];
std::memcpy(dest, source, 10 * sizeof *source);
I think std::copy uses memmove (at least in gcc/libstdc++), but it is not
a bit slower, but a lot ...

memcpy is a bit dangerous, since it can't handle overlapping ranges,
and it isn't typesafe. memmove can handle overlapping ranges, and
hence tends to be used by std::copy for copying POD types.

My benchmarks had std::copy and std::memcpy very similar on GCC:

copy : 1.11
memcpy : 1.093

A difference of a couple of percent isn't something you should worry
about.

Tom
 
T

Thomas Matthews

So I am not the only one to state that std::copy is slower than memcpy.
Indeed, it should not be this way ...

Why?
The function std::copy _is_not_the_same_ as memcpy. They are not
equivalent. A case in point is constructors.

The std::copy function uses the assignment operator to copy objects.
The memcpy function doesn't.

Most people, in C++, don't use memcpy for non-POD types. The
std::copy function is _safer_ than memcpy. For speed critical
applications, the design is changed to minimize the copying of
objects or data (see concept of pointers and references).

Code your program using std::copy. Make another program which
uses memcpy(). Run them. Is the time savings significant?
Profile them. Is there a significant time difference?
Show your friends who are not computer literate. Can they
detect the difference?

--
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.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
 
A

Attila Feher

Thomas said:
So I am not the only one to state that std::copy is slower than
memcpy.

Why?

Because it shouldn't.
The function std::copy _is_not_the_same_ as memcpy. They are not
equivalent. A case in point is constructors.

Fundamental types have no constructors.
The std::copy function uses the assignment operator to copy objects.
The memcpy function doesn't.

When copying fundamental types using std::copy it is a minimum requirement
to have it minimum as fast as memcpy - if the regions do not overlap.
Most people, in C++, don't use memcpy for non-POD types.

And those who do, have serious trouble. :)
The std::copy function is _safer_ than memcpy.

Yes. But when you need speed and you know what you are doing this argument
is mute.
For speed critical
applications, the design is changed to minimize the copying of
objects or data (see concept of pointers and references).

Sure. But if you still need to copy... you may need to find the fastest
solution. According to what I have been told the standard does not stop
std::copy from using memcpy inside if it is applicable. Of course one will
still have the overhead of the action to find out if the things overlap, but
if the copying itself is a big operation this overhead should be minimal.
 
F

franky.backeljauw

When copying fundamental types using std::copy it is a minimum requirement
to have it minimum as fast as memcpy - if the regions do not overlap.


Sure. But if you still need to copy... you may need to find the fastest
solution. According to what I have been told the standard does not stop
std::copy from using memcpy inside if it is applicable. Of course one will
still have the overhead of the action to find out if the things overlap, but
if the copying itself is a big operation this overhead should be minimal.

Indeed, but in gcc/libstdc++ it does not seem to be this way. Looking at
the documentation, it works through templates and uses the function
memmove. But some tests have shown that std::copy and memmove take at
least double the time that memcpy uses ... So why doesn't it use memcpy?
Or is there a std::copy2 that does use memcpy instead?

Regards,

Franky B.
 
W

White Wolf

Indeed, but in gcc/libstdc++ it does not seem to be this way.
Looking at
the documentation, it works through templates and uses the function
memmove. But some tests have shown that std::copy and memmove take at
least double the time that memcpy uses ... So why doesn't it use
memcpy?

Because memcpy does not handle overlapping memory areas properly and
std::copy has to.
Or is there a std::copy2 that does use memcpy instead?

You are mixing the issues here. std::copy and memcopy/memmove has nothing
to do with each other. Nothing. If g++ happend to implement std::copy
using memmove for PODs: great. But it could also use __mymagicmemtransfer
or whatever it wants to. There is no relation between the C functions and
the C++ template..
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top