memset vs fill and iterators vs pointers

Discussion in 'C++' started by Joe C, Aug 23, 2004.

  1. Joe C

    Joe C Guest

    I'm a hobbiest, and made the forray into c++ from non-c type languages about
    a year ago. I was "cleaning up" some code I wrote to make it more "c++
    like" and have a few questions. I'm comfortable using new/delete when
    dealing with arrays, and, so-far haven't used the STL (eg vectors) very much
    when dealing with POD. I'm using a class to dump files into. The class
    puts the file data into a 32-bit array, then offers both 32-bit and char* to
    the file data. The reason I've done this blasphomy is that I need to access
    the file-header information from a byte-oriented viewpoint, but the actual
    data is 32-bit and *will* be word-aligned with respect to the start of the
    file.

    first...is there a better way using streams to do the same?

    second...I've been using memcopy and memset...for POD, are there compelling
    reasons to use copy() and fill/fill_n() instead (when dealing with POD
    arrays)?

    Third...if I load a file into a 32-bit vector and the file byte length is
    not an even multiple of 4-bytes...what happens to the last (incomplete) word
    of the file?

    I hope my questions are clear.

    Joe
    Joe C, Aug 23, 2004
    #1
    1. Advertising

  2. Joe C

    David Hilsee Guest

    "Joe C" <> wrote in message
    news:kqeWc.15534$%...
    > I'm a hobbiest, and made the forray into c++ from non-c type languages

    about
    > a year ago. I was "cleaning up" some code I wrote to make it more "c++
    > like" and have a few questions. I'm comfortable using new/delete when
    > dealing with arrays, and, so-far haven't used the STL (eg vectors) very

    much
    > when dealing with POD. I'm using a class to dump files into. The class
    > puts the file data into a 32-bit array, then offers both 32-bit and char*

    to
    > the file data. The reason I've done this blasphomy is that I need to

    access
    > the file-header information from a byte-oriented viewpoint, but the actual
    > data is 32-bit and *will* be word-aligned with respect to the start of the
    > file.
    >
    > first...is there a better way using streams to do the same?


    I don't understand your question. I'm sure you could use C++ stream classes
    instead of C I/O functions, if that's what you're talking about. I'm not
    sure if that's necessarily better, in your situation.

    > second...I've been using memcopy and memset...for POD, are there

    compelling
    > reasons to use copy() and fill/fill_n() instead (when dealing with POD
    > arrays)?


    While std::memcpy is not guaranteed to work for overlapping regions of
    memory, std::copy works for overlapping sequences. Also, std::memset sets a
    region of memory to all bits zero, and that's not guaranteed to be the
    representation of zero for certain types (e.g. pointers may not use all bits
    zero to represent null). C++'s std::fill does not inherently write "all
    bits zero" to a region of memory. Using the C++ equivalents may help you
    escape some of the gotchas that the C functions bring to the table.

    > Third...if I load a file into a 32-bit vector and the file byte length is
    > not an even multiple of 4-bytes...what happens to the last (incomplete)

    word
    > of the file?


    The std::vector is not so different from the array. In fact, the
    std::vector uses an array internally. See the FAQ
    (http://www.parashift.com/c -faq-lite/), section 34 ("Container classes and
    templates"), question 3 ("Is the storage for a std::vector<T> guaranteed to
    be contiguous?").

    --
    David Hilsee
    David Hilsee, Aug 23, 2004
    #2
    1. Advertising

  3. Joe C

    David Hilsee Guest

    "David Hilsee" <> wrote in message
    news:...
    <snip>
    > While std::memcpy is not guaranteed to work for overlapping regions of
    > memory, std::copy works for overlapping sequences. Also, std::memset sets

    a
    > region of memory to all bits zero, and that's not guaranteed to be the
    > representation of zero for certain types (e.g. pointers may not use all

    bits
    > zero to represent null). C++'s std::fill does not inherently write "all
    > bits zero" to a region of memory. Using the C++ equivalents may help you
    > escape some of the gotchas that the C functions bring to the table.


    Here I assumed that zero was being passed to memset, which is the common
    usage. I also failed to mention that std::fill and std::copy are more
    type-safe than their C equivalents and do not require the programmer to
    consider the size of the elements (using code like numElems *
    sizeof(Element)). In general, they are easier to use.

    <snip>
    > The std::vector is not so different from the array. In fact, the
    > std::vector uses an array internally. See the FAQ
    > (http://www.parashift.com/c -faq-lite/), section 34 ("Container classes

    and
    > templates"), question 3 ("Is the storage for a std::vector<T> guaranteed

    to
    > be contiguous?").


    Here, I should have instead said "In fact, the std::vector uses contiguous
    storage internally".

    --
    David Hilsee
    David Hilsee, Aug 23, 2004
    #3
  4. Joe C

    tom_usenet Guest

    On Mon, 23 Aug 2004 00:31:30 -0400, "Joe C" <>
    wrote:

    >I'm a hobbiest, and made the forray into c++ from non-c type languages about
    >a year ago. I was "cleaning up" some code I wrote to make it more "c++
    >like" and have a few questions. I'm comfortable using new/delete when
    >dealing with arrays, and, so-far haven't used the STL (eg vectors) very much
    >when dealing with POD. I'm using a class to dump files into. The class
    >puts the file data into a 32-bit array, then offers both 32-bit and char* to
    >the file data. The reason I've done this blasphomy is that I need to access
    >the file-header information from a byte-oriented viewpoint, but the actual
    >data is 32-bit and *will* be word-aligned with respect to the start of the
    >file.
    >
    >first...is there a better way using streams to do the same?


    Not really, at least not if your code is already working. You would be
    better off having the class do the reading of the header, so that this
    detail is encapsulated from users of the class. Then it would return a
    pointer to the start of the *real* "32-bit array" (by which I assume
    you mean an array of unsigned int or similar).

    >second...I've been using memcopy and memset...for POD, are there compelling
    >reasons to use copy() and fill/fill_n() instead (when dealing with POD
    >arrays)?


    For POD, copy is like memmove in that it works with overlapping
    ranges.

    fill is different from memset. memset only allows you to set every
    byte to the same value, whereas fill allows you to set every element
    (which may be, e.g., an unsigned int) to the same value.

    >Third...if I load a file into a 32-bit vector and the file byte length is
    >not an even multiple of 4-bytes...what happens to the last (incomplete) word
    >of the file?


    Assuming the vector is 0-initialized, it depends on the byte order
    your platform uses. Either the high order or low order bytes of the
    last value will be 0, which will give the word a particular value.

    Tom
    tom_usenet, Aug 23, 2004
    #4
  5. Joe C

    Joe C Guest

    "tom_usenet" <> wrote in message
    news:...
    > On Mon, 23 Aug 2004 00:31:30 -0400, "Joe C" <>
    > wrote:
    >
    > >I'm a hobbiest, and made the forray into c++ from non-c type languages

    about
    > >a year ago. I was "cleaning up" some code I wrote to make it more "c++
    > >like" and have a few questions. I'm comfortable using new/delete when
    > >dealing with arrays, and, so-far haven't used the STL (eg vectors) very

    much
    > >when dealing with POD. I'm using a class to dump files into. The class
    > >puts the file data into a 32-bit array, then offers both 32-bit and char*

    to
    > >the file data. The reason I've done this blasphomy is that I need to

    access
    > >the file-header information from a byte-oriented viewpoint, but the

    actual
    > >data is 32-bit and *will* be word-aligned with respect to the start of

    the
    > >file.
    > >
    > >first...is there a better way using streams to do the same?

    >
    > Not really, at least not if your code is already working. You would be
    > better off having the class do the reading of the header, so that this
    > detail is encapsulated from users of the class. Then it would return a
    > pointer to the start of the *real* "32-bit array" (by which I assume
    > you mean an array of unsigned int or similar).
    >
    > >second...I've been using memcopy and memset...for POD, are there

    compelling
    > >reasons to use copy() and fill/fill_n() instead (when dealing with POD
    > >arrays)?

    >
    > For POD, copy is like memmove in that it works with overlapping
    > ranges.
    >
    > fill is different from memset. memset only allows you to set every
    > byte to the same value, whereas fill allows you to set every element
    > (which may be, e.g., an unsigned int) to the same value.
    >
    > >Third...if I load a file into a 32-bit vector and the file byte length is
    > >not an even multiple of 4-bytes...what happens to the last (incomplete)

    word
    > >of the file?

    >
    > Assuming the vector is 0-initialized, it depends on the byte order
    > your platform uses. Either the high order or low order bytes of the
    > last value will be 0, which will give the word a particular value.
    >
    > Tom


    Thanks, Tom. Your reply is really helpful. I think that I will leave
    things as they are, since the prog is working and useful for me, and has
    already been fairly thoroughly streamlined. One more question...suppose I
    have large amounts of memory that I want to clear. Do you know if there is
    a speed advantage if it's done using fill with the native integer data-type
    vs using byte-oriented memset? It's a little hard to measure, since the
    operation is really fast in either case...as such I suppose it makes no
    practical difference, huh?

    Thanks again for the reply.

    Joe
    Joe C, Aug 23, 2004
    #5
  6. Joe C

    tom_usenet Guest

    On Mon, 23 Aug 2004 13:09:01 -0400, "Joe C" <>
    wrote:

    >Thanks, Tom. Your reply is really helpful. I think that I will leave
    >things as they are, since the prog is working and useful for me, and has
    >already been fairly thoroughly streamlined. One more question...suppose I
    >have large amounts of memory that I want to clear. Do you know if there is
    >a speed advantage if it's done using fill with the native integer data-type
    >vs using byte-oriented memset? It's a little hard to measure, since the
    >operation is really fast in either case...as such I suppose it makes no
    >practical difference, huh?


    You'll love this article:

    http://www.cuj.com/documents/s=7990/cujcexp1910alexandr/alexandr.htm

    Note that for zeroing large amounts of memory, all reasonable
    techniques work out much the same, since the bottleneck is memory
    bandwidth.

    Tom
    tom_usenet, Aug 24, 2004
    #6
    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. red floyd
    Replies:
    3
    Views:
    3,437
    red floyd
    Aug 6, 2004
  2. Marcin Kaliciñski

    Iterators and reverse iterators

    Marcin Kaliciñski, May 8, 2005, in forum: C++
    Replies:
    1
    Views:
    475
    Kai-Uwe Bux
    May 8, 2005
  3. Replies:
    5
    Views:
    4,158
    CBFalconer
    Dec 29, 2008
  4. , India
    Replies:
    10
    Views:
    1,055
    James Kanze
    Aug 8, 2009
  5. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    650
Loading...

Share This Page