memcpy for copying arrays

[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.

[Attila Feher]

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

[tom_usenet]

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

[franky.backeljauw]

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.

[franky.backeljauw]

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.

[White Wolf]

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

[Kevin Goodsell]

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.

[White Wolf]

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

[franky.backeljauw]

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.

[tom_usenet]

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(des t, 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