Replacement for memcpy call in C++

Discussion in 'C++' started by mthread, Feb 6, 2008.

  1. mthread

    mthread Guest

    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, Feb 6, 2008
    #1
    1. Advertising

  2. * 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?
    Alf P. Steinbach, Feb 6, 2008
    #2
    1. Advertising

  3. mthread

    Greg Comeau Guest

    In article <>,
    mthread <> 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?
    Greg Comeau, Feb 6, 2008
    #3
  4. "mthread" <> 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
    Robbie Hatley, Feb 7, 2008
    #4
  5. In message <dbuqj.76764$>, Robbie Hatley
    <> writes
    >"mthread" <> 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
    Richard Herring, Feb 7, 2008
    #5
  6. mthread

    Pete Becker Guest

    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)
    Pete Becker, Feb 7, 2008
    #6
  7. In message <2008020710152416807-pete@versatilecodingcom>, Pete Becker
    <> 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
    Richard Herring, Feb 7, 2008
    #7
  8. mthread

    Pete Becker Guest

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

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

    James Kanze Guest

    On Feb 7, 4:15 pm, Pete Becker <> 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:
    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
    James Kanze, Feb 8, 2008
    #10
  11. mthread

    James Kanze Guest

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


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


    > >> In message <2008020710152416807-pete@versatilecodingcom>, Pete Becker
    > >><> 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:
    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
    James Kanze, Feb 8, 2008
    #11
  12. mthread

    Pete Becker Guest

    On 2008-02-08 04:46:10 -0500, James Kanze <> said:

    > On Feb 7, 4:15 pm, Pete Becker <> 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)
    Pete Becker, Feb 8, 2008
    #12
  13. In message <2008020809065616807-pete@versatilecodingcom>, Pete Becker
    <> writes
    >On 2008-02-08 04:46:10 -0500, James Kanze <> said:
    >
    >> On Feb 7, 4:15 pm, Pete Becker <> 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
    Richard Herring, Feb 8, 2008
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Edwards
    Replies:
    1
    Views:
    567
    Dave Rahardja
    Aug 7, 2003
  2. David Bradley
    Replies:
    0
    Views:
    524
    David Bradley
    Aug 7, 2003
  3. Ninan Thomas
    Replies:
    3
    Views:
    405
    Kevin Goodsell
    Aug 22, 2003
  4. Bren
    Replies:
    8
    Views:
    2,008
    Stephen Howe
    Sep 4, 2003
  5. K.J. 44
    Replies:
    3
    Views:
    96
    K.J. 44
    Nov 28, 2006
Loading...

Share This Page