471,571 Members | 1,020 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,571 software developers and data experts.

memcpy for copying arrays

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.
Jul 19 '05 #1
13 17294
fr***************@ua.ac.be wrote:
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.

--
Attila aka WW
Jul 19 '05 #2
On Tue, 16 Sep 2003 12:55:09 +0200, fr***************@ua.ac.be wrote:
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.
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++.
- 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
Jul 19 '05 #3
On Tue, 16 Sep 2003, tom_usenet wrote:
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)?
- 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.


But it can be considered as the most optimal available function to copy
arrays?
- 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).


And how is this done? E.g. how do I copy an array of doubles?
- 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).


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

Regards,

Franky B.
Jul 19 '05 #4
On Tue, 16 Sep 2003, Attila Feher wrote:
- 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.


But if it is a c++ function, then in which sense is std::copy an
alternative?
- What else should I know about this function?


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.
Jul 19 '05 #5
fr***************@ua.ac.be wrote:
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.
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?


Look at your compilers documentation. Or use google.
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 ...


It might be, but that is an implementation issue.

--
WW aka Attila
Jul 19 '05 #6
fr***************@ua.ac.be wrote:
Or is there a c++ alternative to it?
std::copy.

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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #7
fr***************@ua.ac.be wrote:
Or is there a c++ alternative to it?
std::copy.


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).
- What else should I know about this function?


It is a C library function.


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.

--
WW aka Attila
Jul 19 '05 #8
On Tue, 16 Sep 2003, White Wolf wrote:
- What else should I know about this function?

It is a C library function.


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.


So I am not the only one to state that std::copy is slower than memcpy.
Indeed, it should not be this way ...
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.


Okay, thanks for the information.

Regards,

Franky B.
Jul 19 '05 #9
On Tue, 16 Sep 2003 22:03:06 +0200, fr***************@ua.ac.be wrote:
On Tue, 16 Sep 2003, tom_usenet wrote:
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++"?


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 isstd::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.
>- 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.


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/...r/alexandr.htm
>- 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).


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);
>- 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).


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
Jul 19 '05 #10
fr***************@ua.ac.be wrote:
On Tue, 16 Sep 2003, White Wolf wrote: 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

Jul 19 '05 #11
Thomas Matthews wrote:
fr***************@ua.ac.be wrote:
On Tue, 16 Sep 2003, White Wolf wrote: So I am not the only one to state that std::copy is slower than
memcpy.
Indeed, it should not be this way ...


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.

--
Attila aka WW
Jul 19 '05 #12
On Wed, 17 Sep 2003, Attila Feher wrote:
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.
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.


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.
Jul 19 '05 #13
fr***************@ua.ac.be wrote:
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..

--
WW aka Attila
Jul 19 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by spoc | last post: by
6 posts views Thread by Samee Zahur | last post: by
1 post views Thread by Amon Tse | last post: by
33 posts views Thread by Case | last post: by
39 posts views Thread by Martin Jørgensen | last post: by
15 posts views Thread by Frederick Gotham | last post: by
18 posts views Thread by Mark | last post: by
3 posts views Thread by Nope | last post: by
11 posts views Thread by mthread | last post: by
reply views Thread by leo001 | last post: by
reply views Thread by lumer26 | last post: by
reply views Thread by Vinnie | last post: by
reply views Thread by lumer26 | last post: by
reply views Thread by lumer26 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.