473,230 Members | 1,359 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,230 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 17456
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

10
by: spoc | last post by:
I have been using memcpy to copy one class to another of the same type. There are reasons why I had to do this bug am getting some odd crashes and maybe I'm doing something dodgy copying classes...
6
by: Samee Zahur | last post by:
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...
1
by: Amon Tse | last post by:
Dear All, I am new to unicode developement in C++. Could anyone give me an idea whether the following (1), (2) and (3) are equivalent and correct in semantics: wchar_t src = L'ABCDE';...
33
by: Case | last post by:
#define SIZE 100 #define USE_MEMCPY int main(void) { char a; char b; int n; /* code 'filling' a */
39
by: Martin Jørgensen | last post by:
Hi, I'm relatively new with C-programming and even though I've read about pointers and arrays many times, it's a topic that is a little confusing to me - at least at this moment: ---- 1)...
15
by: Frederick Gotham | last post by:
What's the canonical way to copy an array in C++? If we're copying a POD, we can use memcpy (but there could be a more efficient alternative if we know that the blocks are suitably aligned). ...
18
by: Mark | last post by:
Hi List, I want to write a function to copy some data out of a hardware buffer. The hardware can change the contents of this buffer without it being written to by my function. I want to use...
3
by: Nope | last post by:
LO everybody, I have a string (defined as a character array), and a structure which comprises of unsigned chars, chars or char arrays. I want to copy the 'string' into the structure, in one...
11
by: mthread | last post by:
Hi, I would like to know if C++ has a class equivalent to memcpy and its associated functions available in C.
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: jianzs | last post by:
Introduction Cloud-native applications are conventionally identified as those designed and nurtured on cloud infrastructure. Such applications, rooted in cloud technologies, skillfully benefit from...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...

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.