(newbie)Technically what's the difference between memset() andmemcpy() functions?

Discussion in 'C++' started by sam, Sep 10, 2008.

  1. sam

    sam Guest

    (newbie)Technically what's the difference between memset() and
    memcpy() functions?
     
    sam, Sep 10, 2008
    #1
    1. Advertising

  2. sam wrote:
    > (newbie)Technically what's the difference between memset() and
    > memcpy() functions?


    You could read the manual ...

    memset() sets a memory area to a certain value
    memcpy() copies one memory area to another area

    Bart
     
    Bart Friederichs, Sep 10, 2008
    #2
    1. Advertising

  3. sam

    Road.Tang Guest

    On Sep 10, 8:59 pm, sam <> wrote:
    > (newbie)Technically what's the difference between memset() and
    > memcpy() functions?


    just as the naming of the funcation.

    memset is used to *set* a range of memory to the unique value.

    #define BUFSIZE 1024
    char buf[BUFSIZE];
    memset(buf, 0, sizeof(BUFSIZE)); /* set [buf, buf+BUFSIZE) range
    memory to 0 */

    whereas, memcpy is used to *copy* a range of memory into another
    range of memory.

    char buf1[BUFSIZE];
    char buf2[BUFSIZE] = { 'a', 'b', 'c' };

    memcpy(buf1, buf2, sizeof(buf2)); /* copy the value of buf2 into buf1
    */

    Roadt
     
    Road.Tang, Sep 10, 2008
    #3
  4. sam

    James Kanze Guest

    On Sep 10, 2:59 pm, sam <> wrote:
    > (newbie)Technically what's the difference between memset() and
    > memcpy() functions?


    Well, formally, they do different things. Practically, who
    cares? You'd never use either in a C++ program.

    --
    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, Sep 10, 2008
    #4
  5. sam

    red floyd Guest

    On Sep 10, 9:34 am, James Kanze <> wrote:
    > On Sep 10, 2:59 pm, sam <> wrote:
    >
    > > (newbie)Technically what's the difference between memset() and
    > > memcpy() functions?

    >
    > Well, formally, they do different things.  Practically, who
    > cares?  You'd never use either in a C++ program.
    >


    Not necessarily. If you are using a library with a C API, and they
    require a zeroed POD struct as a param, memset is your easiest bet.
     
    red floyd, Sep 10, 2008
    #5
  6. sam

    Guest

    On 10 Sep, 13:59, sam <> wrote:
    > (newbie)Technically what's the difference between memset() and
    > memcpy() functions?


    A more interesting question would be - what's the difference between
    memcpy() and memmove()?

    The answer to this one is that memcpy can go wrong if the place it's
    moving from and the place it's moving to overlap. As a simple example,
    suppose you ask it to copy 20 bytes from addresses [100-119] to
    addresses [105-124]. It might copy the contents of [100] to [105],
    then the contents of [101] to [106], etc, but when it gets to [105],
    instead of copying what was originally in [105], this has already been
    overwritten and so what it reads, and copies to [110], is what was
    originally in [100]. So instead of getting a copy of what was in
    [100-119], you get four copies of what was in [100-105].

    memmove() is guaranteed not to go wrong in this way.

    Hope that helps.
    Paul.
     
    , Sep 10, 2008
    #6
  7. sam

    James Kanze Guest

    On Sep 10, 10:20 pm, red floyd <> wrote:
    > On Sep 10, 9:34 am, James Kanze <> wrote:


    > > On Sep 10, 2:59 pm, sam <> wrote:


    > > > (newbie)Technically what's the difference between memset() and
    > > > memcpy() functions?


    > > Well, formally, they do different things. Practically, who
    > > cares? You'd never use either in a C++ program.


    > Not necessarily. If you are using a library with a C API, and
    > they require a zeroed POD struct as a param, memset is your
    > easiest bet.


    The problem is that memset doesn't necessarily zero the
    structure correctly. The correct solution to the above (even in
    C) is to declare a static instance of the struct, and assign it
    to the struct you want to zero.

    --
    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, Sep 11, 2008
    #7
  8. Yannick Tremblay wrote:
    > Read about structure initialisation and remove all these pointless
    > memset from your code. For example:
    > http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=171


    Please, don't link to articles with such low quality. I did read up to sixth
    line (excluding titles) and there were more technical errors than words.

    --
    Gennaro Prota | name.surname yahoo.com
    Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
    Do you need expertise in C++? I'm available.
     
    Gennaro Prota, Sep 11, 2008
    #8
  9. sam

    Default User Guest

    Re: (newbie)Technically what's the difference between memset() and memcpy() functions?

    Yannick Tremblay wrote:

    > In article
    > <>,
    > <> wrote: >On 10 Sep, 13:59, sam <>


    > > A more interesting question would be - what's the difference between
    > > memcpy() and memmove()?
    > >
    > > The answer to this one is that memcpy can go wrong if the place it's
    > > moving from and the place it's moving to overlap.


    > > memmove() is guaranteed not to go wrong in this way.

    >
    > Strictly speaking, memcpy did not go wrong. It did exactly what was
    > asked for which is copy byte by byte 20 bytes from address 100 to
    > address 105.


    No, strictly speaking, use of memcpy() with overlapping objects is
    undefined behavior. There is no defined behavior for undefined
    behavior, so you can't call any particular behavior "right" or "wrong".




    Brian
     
    Default User, Sep 11, 2008
    #9
  10. sam

    James Kanze Guest

    On Sep 12, 3:07 am, Francis Litterio <> wrote:
    > James Kanze wrote:
    > > On Sep 10, 10:20 pm, red floyd wrote:
    > >> On Sep 10, 9:34 am, James Kanze wrote:


    > >> > On Sep 10, 2:59 pm, sam wrote:


    > >> > > (newbie)Technically what's the difference between
    > >> > > memset() and memcpy() functions?


    > >> > Well, formally, they do different things. Practically, who
    > >> > cares? You'd never use either in a C++ program.


    > >> Not necessarily. If you are using a library with a C API, and
    > >> they require a zeroed POD struct as a param, memset is your
    > >> easiest bet.


    > > The problem is that memset doesn't necessarily zero the
    > > structure correctly. The correct solution to the above
    > > (even in C) is to declare a static instance of the struct,
    > > and assign it to the struct you want to zero.


    > Is it acceptable to do this:


    > Foo x = { 0 };


    > assuming Foo is a POD struct.


    Or even:
    Foo x = {} ;
    if you need a variable. In C++ (but not in C), it's also
    possible to write Foo() to obtain a zero initialized temporary
    of type Foo.

    In fact, my suggestion is somewhat dated, going back to the time
    when I was programming in C (which was before C90, when some
    compilers didn't allow agglomerate initialization for local
    variables).

    --
    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, Sep 12, 2008
    #10
  11. On 12 Sep, 09:57, (Yannick Tremblay) wrote:
    > In article <>,
    > Default User <> wrote:
    > >Yannick Tremblay wrote:
    > >> In article
    > >> <>,
    > >> <> wrote: >On 10 Sep, 13:59, sam <>


    > >> > A more interesting question would be - what's the difference between
    > >> > memcpy() and memmove()?

    >
    > >> > The answer to this one is that memcpy can go wrong if the place it's
    > >> > moving from and the place it's moving to overlap.

    >
    > >> > memmove() is guaranteed not to go wrong in this way.

    >
    > >> Strictly speaking, memcpy did not go wrong. It did exactly what was
    > >> asked for which is copy byte by byte 20 bytes from address 100 to
    > >> address 105.

    >
    > That part of my comment was a bit tongue in cheek. :)
    >
    > >No, strictly speaking, use of memcpy() with overlapping objects is
    > >undefined behavior. There is no defined behavior for undefined
    > >behavior, so you can't call any particular behavior "right" or "wrong".

    >
    > Sorry, this is not undefined behaviour with memcpy().


    yes it is. This is a *direct quote* from The Standard [1]

    "If copying takes place objects that overlap, the behavior is
    undefined"


    > memcpy()
    > doesn't care if you try to copy overlapping POD array or C++ objects
    > overlapping. memcpy() only works with bytes, it is not concerned
    > about wether these bytes represent an object or a char[] nor if the
    > destination overlaps with the source, it just does it exactly as
    > instructed. There result is perfectly defined and predictable. No
    > undefined behaviour there.


    that's not what the standard says.


    > However, if you use memcpy to copy an object partly overlapping over
    > itself, then you are corrupting memory. Attempting to use this
    > corrupted memory as a C++ object is undefined behaviour.
    >
    > Essentially, what you are doing is taking the (void *) which is the
    > output of the memcpy and casting it to a class type. This is
    > undefined behaviour if the (void *) did not point to a object of the
    > class in the first place.



    [1] I'm quoting the ANSI *C* standard, because I had it handy.
    I'm assuming C++ has not chnaged in this area.

    --
    Nick Keighley
     
    Nick Keighley, Sep 12, 2008
    #11
  12. sam

    James Kanze Guest

    On Sep 12, 12:29 pm, Nick Keighley <>
    wrote:
    > On 12 Sep, 09:57, (Yannick Tremblay) wrote:
    > > In article <>,
    > > Default User <> wrote:


    [...]
    > > >> Strictly speaking, memcpy did not go wrong. It did
    > > >> exactly what was asked for which is copy byte by byte 20
    > > >> bytes from address 100 to address 105.


    > > That part of my comment was a bit tongue in cheek. :)


    > > >No, strictly speaking, use of memcpy() with overlapping
    > > >objects is undefined behavior. There is no defined behavior
    > > >for undefined behavior, so you can't call any particular
    > > >behavior "right" or "wrong".


    > > Sorry, this is not undefined behaviour with memcpy().


    > yes it is. This is a *direct quote* from The Standard [1]


    > "If copying takes place objects that overlap, the behavior is
    > undefined"


    [...]

    > [1] I'm quoting the ANSI *C* standard, because I had it handy.
    > I'm assuming C++ has not chnaged in this area.


    The C++ simply says that memcpy has the signature and the
    behavior described in Standard 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, Sep 12, 2008
    #12
    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. jakk
    Replies:
    4
    Views:
    12,496
  2. chenyu
    Replies:
    1
    Views:
    772
    Alex Martelli
    Nov 7, 2003
  3. Lax
    Replies:
    2
    Views:
    522
    Richard Tobin
    Apr 13, 2008
  4. xliiv
    Replies:
    19
    Views:
    375
    Adam Tauno Williams
    Mar 24, 2012
  5. OwlHoot
    Replies:
    0
    Views:
    137
    OwlHoot
    Aug 23, 2007
Loading...

Share This Page