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.

* 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

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

In article <acd73157-9d82-46e2-8d50-8a731a0e6fd9@c23g2000hsa.googlegroups.com>,
mthread <rjkumr@gmail.com> wrote:
> 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.
--
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

"mthread" <rjkumr@gmail.com> wrote:

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

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant

In message <dbuqj.76764$m_6.65228@fe01.news.easynews.com>, Robbie Hatley
<see.my.signature@for.my.email.address> writes
>"mthread" <rjkumr@gmail.com> wrote:
>
>> 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.

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

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.

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

In message <2008020710152416807-pete@versatilecodingcom>, Pete Becker
<pete@versatilecoding.com> writes
>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?

--
Richard Herring

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

> In message <2008020710152416807-pete@versatilecodingcom>, Pete Becker
> <pete@versatilecoding.com> writes
>> 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.

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

In message <2008020711353816807-pete@versatilecodingcom>, Pete Becker
<pete@versatilecoding.com> writes
>On 2008-02-07 11:09:04 -0500, Richard Herring <junk@[127.0.0.1]> said:
>
>> In message <2008020710152416807-pete@versatilecodingcom>, Pete Becker
>><pete@versatilecoding.com> writes
>>> 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.

--
Richard Herring

On Feb 7, 4:15 pm, Pete Becker <p...@versatilecoding.com> wrote:
> 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 (GABI Software) email:james.kanze@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

On Feb 7, 7:16 pm, Richard Herring <junk@[127.0.0.1]> wrote:
> In message <2008020711353816807-pete@versatilecodingcom>, Pete Becker
> <p...@versatilecoding.com> writes

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

> >> In message <2008020710152416807-pete@versatilecodingcom>, Pete Becker
> >><p...@versatilecoding.com> writes
> >>> 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.)

--
James Kanze (GABI Software) email:james.kanze@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

On 2008-02-08 04:46:10 -0500, James Kanze <james.kanze@gmail.com> said:

> On Feb 7, 4:15 pm, Pete Becker <p...@versatilecoding.com> wrote:
>> 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."

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

In message <2008020809065616807-pete@versatilecodingcom>, Pete Becker
<pete@versatilecoding.com> writes
>On 2008-02-08 04:46:10 -0500, James Kanze <james.kanze@gmail.com> said:
>
>> On Feb 7, 4:15 pm, Pete Becker <p...@versatilecoding.com> wrote:
>>> 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:

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