Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   memset vs fill and iterators vs pointers (http://www.velocityreviews.com/forums/t285165-memset-vs-fill-and-iterators-vs-pointers.html)

Joe C 08-23-2004 04:31 AM

memset vs fill and iterators vs pointers
 
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







David Hilsee 08-23-2004 12:54 PM

Re: memset vs fill and iterators vs pointers
 
"Joe C" <jkc8289@bellsouth.net> wrote in message
news:kqeWc.15534$%n4.11421@bignews6.bellsouth.net. ..
> 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 08-23-2004 01:14 PM

Re: memset vs fill and iterators vs pointers
 
"David Hilsee" <davidhilseenews@yahoo.com> wrote in message
news:yd-dnbIxoo5qdbTcRVn-vA@comcast.com...
<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



tom_usenet 08-23-2004 02:41 PM

Re: memset vs fill and iterators vs pointers
 
On Mon, 23 Aug 2004 00:31:30 -0400, "Joe C" <jkc8289@bellsouth.net>
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

Joe C 08-23-2004 05:09 PM

Re: memset vs fill and iterators vs pointers
 

"tom_usenet" <tom_usenet@hotmail.com> wrote in message
news:170ki056r00goj8o7oe64rddfda025t8pk@4ax.com...
> On Mon, 23 Aug 2004 00:31:30 -0400, "Joe C" <jkc8289@bellsouth.net>
> 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



tom_usenet 08-24-2004 11:51 AM

Re: memset vs fill and iterators vs pointers
 
On Mon, 23 Aug 2004 13:09:01 -0400, "Joe C" <jkc8289@bellsouth.net>
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/...r/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


All times are GMT. The time now is 07:36 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.