468,512 Members | 1,413 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,512 developers. It's quick & easy.

Replacement for memcpy call in C++

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.

Feb 6 '08 #1
8 4623
On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[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.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Feb 7 '08 #2
In message <2008020710152416807-pete@versatilecodingcom>, Pete Becker
<pe**@versatilecoding.comwrites
>On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[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?

--
Richard Herring
Feb 7 '08 #3
On 2008-02-07 11:09:04 -0500, Richard Herring <ju**@[127.0.0.1]said:
In message <2008020710152416807-pete@versatilecodingcom>, Pete Becker
<pe**@versatilecoding.comwrites
>On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[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.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Feb 7 '08 #4
In message <2008020711353816807-pete@versatilecodingcom>, Pete Becker
<pe**@versatilecoding.comwrites
>On 2008-02-07 11:09:04 -0500, Richard Herring <ju**@[127.0.0.1]said:
>In message <2008020710152416807-pete@versatilecodingcom>, Pete Becker
<pe**@versatilecoding.comwrites
>>On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[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.

--
Richard Herring
Feb 7 '08 #5
On Feb 7, 4:15 pm, Pete Becker <p...@versatilecoding.comwrote:
On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[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 (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Feb 8 '08 #6
On Feb 7, 7:16 pm, Richard Herring <ju**@[127.0.0.1]wrote:
In message <2008020711353816807-pete@versatilecodingcom>, Pete Becker
<p...@versatilecoding.comwrites
On 2008-02-07 11:09:04 -0500, Richard Herring <ju**@[127.0.0.1]said:
In message <2008020710152416807-pete@versatilecodingcom>, Pete Becker
<p...@versatilecoding.comwrites
On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[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.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Feb 8 '08 #7
On 2008-02-08 04:46:10 -0500, James Kanze <ja*********@gmail.comsaid:
On Feb 7, 4:15 pm, Pete Becker <p...@versatilecoding.comwrote:
>On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[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."

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Feb 8 '08 #8
In message <2008020809065616807-pete@versatilecodingcom>, Pete Becker
<pe**@versatilecoding.comwrites
>On 2008-02-08 04:46:10 -0500, James Kanze <ja*********@gmail.comsaid:
>On Feb 7, 4:15 pm, Pete Becker <p...@versatilecoding.comwrote:
>>On 2008-02-07 09:40:58 -0500, Richard Herring <ju**@[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:
>>>>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.
and in the second case ("disparate data types") naively applying memcpy
is unlikely to have a happy outcome.

--
Richard Herring
Feb 8 '08 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

35 posts views Thread by Christopher Benson-Manica | last post: by
33 posts views Thread by Case | last post: by
6 posts views Thread by myhotline | last post: by
1 post views Thread by remove the CAPS | last post: by
3 posts views Thread by ebrahimbandookwala | last post: by
39 posts views Thread by Martin Jørgensen | last post: by
6 posts views Thread by Eric | last post: by
18 posts views Thread by Mark | last post: by
1 post views Thread by fmendoza | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.