Replacement for memcpy call in C++

[mthread]

Hi,
I am copying data from one buffer(this data is a binary data not
string) to another buffer. Earlier when I used C, I used the memcpy
function call to copy the values. Is there any equivalent replacement
in C++ for this call.

 

[Alf P. Steinbach]

* mthread:

I am copying data from one buffer(this data is a binary data not
string) to another buffer. Earlier when I used C, I used the memcpy
function call to copy the values. Is there any equivalent replacement
in C++ for this call.

If for example your buffers are

char* buffer1;
char* buffer2;

then in C++ the natural way would be to use vectors instead,

std::vector<char> buffer1;
std::vector<char> buffer2;

then to copy just assign,

buffer1 = buffer2;

In some situations it may be necessary to do something like mempcy
instead of choosing a more convenient representation, and then consider
std::copy.


Cheers, & hth.,

- Alf

 

[Greg Comeau]

I am copying data from one buffer(this data is a binary data not
string) to another buffer. Earlier when I used C, I used the memcpy
function call to copy the values. Is there any equivalent replacement
in C++ for this call.

The direct answer is that memcpy is probably the best memcpy
provided, and you can get at it with C++ too (via string.h, or
cstring as std::memcpy). The indirect answer is that you may want
to change how you are doing your buffering, perhaps with
a std::string or std::vector, etc and use their respective copying.

 

[Robbie Hatley]

Hi,
I am copying data from one buffer(this data is a binary data not
string) to another buffer. Earlier when I used C, I used the memcpy
function call to copy the values. Is there any equivalent replacement
in C++ for this call.

Yes. std::memcpy(). It's a direct replacement.

Ok, yes, I know, that's not what you meant. But sometimes the best
tool in C++ to do a particular job is the tool inherited from C.
It really depends on what you're doing. What kind of data is it,
where did it come from, how is it formatted, where will it be
stored, and how is it used?

If the source is a raw stream of bytes, (say from a communications
line), or the source and destination are disparate data types and
can not be made the same type (for whatever reason), then just memcpy.
Brutal, dangerous, and requires that you know what you're doing, yes;
but beautifully simple and efficient.

Otherwise, if you can arrange for the source and destination to be
the same data type, you can just assign one to the other, either
using arrays and for-loops and pointers, or (preferably) using
std containers and iterators and algorithms.

 

[Richard Herring]

Yes. std::memcpy(). It's a direct replacement.

Ok, yes, I know, that's not what you meant. But sometimes the best
tool in C++ to do a particular job is the tool inherited from C.
It really depends on what you're doing. What kind of data is it,
where did it come from, how is it formatted, where will it be
stored, and how is it used?

If the source is a raw stream of bytes, (say from a communications
line), or the source and destination are disparate data types and
can not be made the same type (for whatever reason), then just memcpy.
Brutal, dangerous, and requires that you know what you're doing, yes;
but beautifully simple and efficient.

Why not simply use std::copy? (don't forget pointers are iterators too
;-)

It's a good deal safer, and likely to be just as efficient, because it's
probably specialised to call memmove or its moral equivalent whenever
it's safe to do so.

 

[Pete Becker]

Why not simply use std::copy? (don't forget pointers are iterators too ;-)

It's a good deal safer, and likely to be just as efficient, because
it's probably specialised to call memmove or its moral equivalent
whenever it's safe to do so.

Given two pointers and a length, copy is not safer than memcpy.

 

[Richard Herring]

Given two pointers and a length, copy is not safer than memcpy.

What, even if they point to non-POD objects?

 

[Pete Becker]

What, even if they point to non-POD objects?

Sighg. Okay: given that memcpy is acceptable for the two pointers and
the length, copy is not safer than memcpy.

 

[Richard Herring]

On 2008-02-07 09:40:58 -0500, Richard Herring <junk@[127.0.0.1]> said:

Why not simply use std::copy? (don't forget pointers are iterators
too ;-)
It's a good deal safer, and likely to be just as efficient,
because it's probably specialised to call memmove or its moral
equivalent whenever it's safe to do so.
Given two pointers and a length, copy is not safer than memcpy.

What, even if they point to non-POD objects?

Sighg. Okay: given that memcpy is acceptable for the two pointers and
the length, copy is not safer than memcpy.

Agreed, but it's no less safe and probably no slower.

(And if the ranges overlap, you may have to stop and think whether you
really meant memcpy and not memmove.)

I just don't like to see solutions implying that copying objects is
merely a matter of shuffling bits around. Sooner or later one gets
bitten.

 

[James Kanze]

On 2008-02-07 09:40:58 -0500, Richard Herring <junk@[127.0.0.1]> said:

Why not simply use std::copy? (don't forget pointers are
iterators too ;-)
It's a good deal safer, and likely to be just as efficient, because
it's probably specialised to call memmove or its moral equivalent
whenever it's safe to do so.

Given two pointers and a length, copy is not safer than memcpy.

There are two potential errors with memcpy: the length is wrong,
and that memcpy doesn't have appropriate semantics for the type
being copied. Copy only suffers from the first of these.

 

[James Kanze]

In message <2008020711353816807-pete@versatilecodingcom>, Pete Becker

On 2008-02-07 11:09:04 -0500, Richard Herring <junk@[127.0.0.1]> said:

In message <2008020710152416807-pete@versatilecodingcom>, Pete Becker
On 2008-02-07 09:40:58 -0500, Richard Herring <junk@[127.0.0.1]> said:
Why not simply use std::copy? (don't forget pointers are iterators
too ;-)
It's a good deal safer, and likely to be just as efficient,
because it's probably specialised to call memmove or its moral
equivalent whenever it's safe to do so.
Given two pointers and a length, copy is not safer than memcpy.
What, even if they point to non-POD objects?

Sighg. Okay: given that memcpy is acceptable for the two pointers and
the length, copy is not safer than memcpy.

Agreed, but it's no less safe and probably no slower.

(And if the ranges overlap, you may have to stop and think whether you
really meant memcpy and not memmove.)

If the ranges overlap, you may have to think whether you need to
use reverse iterators or not with std::copy. If you don't know
whether they overlap or not, memmove always works, but you can't
use std::copy. (Note that there is no standard conformant way
of determining whether two ranges overlap, given only the
pointers and their length. memmove cannot be implemented in
standard conformant, portable C.)

 

[Pete Becker]

On 2008-02-07 09:40:58 -0500, Richard Herring <junk@[127.0.0.1]> said:

Why not simply use std::copy? (don't forget pointers are
iterators too ;-)
It's a good deal safer, and likely to be just as efficient, because
it's probably specialised to call memmove or its moral equivalent
whenever it's safe to do so.

Given two pointers and a length, copy is not safer than memcpy.

There are two potential errors with memcpy: the length is wrong,
and that memcpy doesn't have appropriate semantics for the type
being copied. Copy only suffers from the first of these.

Right. But given that memcpy works, which is the premise for replacing
it, copy is not inherently "a good deal safer."

 

[Richard Herring]

On 2008-02-07 09:40:58 -0500, Richard Herring <junk@[127.0.0.1]> said:

Why not simply use std::copy? (don't forget pointers are
iterators too ;-)

It's a good deal safer, and likely to be just as efficient, because
it's probably specialised to call memmove or its moral equivalent
whenever it's safe to do so.

Given two pointers and a length, copy is not safer than memcpy.

There are two potential errors with memcpy: the length is wrong,
and that memcpy doesn't have appropriate semantics for the type
being copied. Copy only suffers from the first of these.

Right. But given that memcpy works, which is the premise for replacing
it, copy is not inherently "a good deal safer."

"Given that memcpy works" is *not* a premise. It's a proviso that
practically begs the question. The original premise was this:

and in the second case ("disparate data types") naively applying memcpy
is unlikely to have a happy outcome.