Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > memset doesn't work as expected

Reply
Thread Tools

memset doesn't work as expected

 
 
thomas
Guest
Posts: n/a
 
      02-20-2008
I allocated a piece of memory and use memset to set it to 0.
------------------------------------
int *graph = new int[16];
memset(graph, 0, sizeof(graph));
for(int i=0;i<4;i++){
for(int j=0;j<4;j++)
cout<<graph[i*n+j]<<" ";
cout<<endl;
}
--------------------------------
But I found that the output is really strange -- graph[0][1] is always
a large number.
I expected the output will all be 0.
 
Reply With Quote
 
 
 
 
thomas
Guest
Posts: n/a
 
      02-20-2008
or can I new a piece of memory and set it to zero in the mean time?
 
Reply With Quote
 
 
 
 
Lars Uffmann
Guest
Posts: n/a
 
      02-20-2008
thomas wrote:
> I allocated a piece of memory and use memset to set it to 0.
> ------------------------------------
> int *graph = new int[16];
> memset(graph, 0, sizeof(graph));


sizeof (graph) should be sizeof (int *) - which is definitely not sizeof
(int)*16. So you are only setting the first sizeof(int *) bytes in the
array to zero.

Try memset (graph, 0, sizeof (int)*16) instead.
 
Reply With Quote
 
peter koch
Guest
Posts: n/a
 
      02-20-2008
On 20 Feb., 13:28, thomas <(E-Mail Removed)> wrote:
> I allocated a piece of memory and use memset to set it to 0.
> ------------------------------------
> int *graph = new int[16];
> memset(graph, 0, sizeof(graph));
> for(int i=0;i<4;i++){
> * * for(int j=0;j<4;j++)
> * * * * cout<<graph[i*n+j]<<" ";
> * * cout<<endl;}
>
> --------------------------------
> But I found that the output is really strange -- graph[0][1] is always
> a large number.
> I expected the output will all be 0.


This is because you do not use std::vector. Always use high-level
constructs unless you have a good reason not to: low level programming
requires you to take care of lots of details that are irrelevant to
your problem and might be difficult to get right. One of your problems
here is that sizeof did not return what you thought, but there are
other problems lurking!

/Peter
 
Reply With Quote
 
Lars Uffmann
Guest
Posts: n/a
 
      02-20-2008
peter koch wrote:
> This is because you do not use std::vector. Always use high-level
> constructs unless you have a good reason not to: low level programming
> requires you to take care of lots of details that are irrelevant to
> your problem and might be difficult to get right.


I fail to see a problem other than getting the size right in this
case... Isn't speed always a "good reason" to do low level programming?
I am somewhat estranged here by your general "always use high-level
constructs" statement.

> One of your problems here is that sizeof did not return what you
> thought, but there are other problems lurking!


Care to enlighten me, for one? I'm curious. Assuming he has set n to
4 first and should synchronize n with the max value for j, and should
probably link the size of the array construction to that with a
const/variable, I currently see no other problems...

Best Regards,

Lars

 
Reply With Quote
 
Lionel B
Guest
Posts: n/a
 
      02-20-2008
On Wed, 20 Feb 2008 04:35:26 -0800, peter koch wrote:

> On 20 Feb., 13:28, thomas <(E-Mail Removed)> wrote:
>> I allocated a piece of memory and use memset to set it to 0.
>> ------------------------------------
>> int *graph = new int[16];
>> memset(graph, 0, sizeof(graph));
>> for(int i=0;i<4;i++){
>> * * for(int j=0;j<4;j++)
>> * * * * cout<<graph[i*n+j]<<" ";
>> * * cout<<endl;}
>>
>> --------------------------------
>> But I found that the output is really strange -- graph[0][1] is always
>> a large number.
>> I expected the output will all be 0.

>
> This is because you do not use std::vector. Always use high-level
> constructs unless you have a good reason not to:


Steady on, that could come across as somewhat patronising. You do not
know for sure that the OP does not have a "good reason not to use a high-
level construct". Ok, maybe unlikely in this case - but then again, to
learn about (the dangers of) low-level constructs might be a valid reason
to try them out and, as the OP has done, get some feedback on the results.

> low level programming
> requires you to take care of lots of details that are irrelevant to your
> problem and might be difficult to get right.


Again: you don't know what the OP is trying to achieve (they don't say).

--
Lionel B
 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      02-20-2008
Lars Uffmann wrote:

> peter koch wrote:
>> This is because you do not use std::vector. Always use high-level
>> constructs unless you have a good reason not to: low level programming
>> requires you to take care of lots of details that are irrelevant to
>> your problem and might be difficult to get right.

>
> I fail to see a problem other than getting the size right in this
> case... Isn't speed always a "good reason" to do low level programming?


No, there are many cases where speed is not a good reason to engage in low
level programming.

> I am somewhat estranged here by your general "always use high-level
> constructs" statement.


Well, if you leave out the "unless you have a good reason not to" part, the
statement is false.


[snip]


Best

Kai-Uwe Bux
 
Reply With Quote
 
Richard Herring
Guest
Posts: n/a
 
      02-20-2008
In message <(E-Mail Removed)>, Lars Uffmann
<(E-Mail Removed)> writes
>peter koch wrote:
>> This is because you do not use std::vector. Always use high-level
>> constructs unless you have a good reason not to: low level programming
>> requires you to take care of lots of details that are irrelevant to
>> your problem and might be difficult to get right.

>
>I fail to see a problem other than getting the size right in this
>case... Isn't speed always a "good reason" to do low level programming?


Not if it conflicts with clarity and maintainability. Less still when
it's probably fictional (it's unlikely that initialising a vector of
ints takes any longer than using new[] and memset.)

In any case, first you'd have to show (a) that the high-level solution
is too slow, (b) the low-level solution is actually faster, and (c) that
the speed increase actually has a measurable effect on the performance
of the program as a whole.

>I am somewhat estranged here by your general "always use high-level
>constructs" statement.
>
>> One of your problems here is that sizeof did not return what you
>> thought, but there are other problems lurking!

>
>Care to enlighten me, for one? I'm curious. Assuming he has set n to
>4 first and should synchronize n with the max value for j, and
>should probably link the size of the array construction to that with a
>const/variable,


That's three assumptions already

>I currently see no other problems...


Until he decides to switch from int to some user-defined type that isn't
POD...

--
Richard Herring
 
Reply With Quote
 
Lars Uffmann
Guest
Posts: n/a
 
      02-20-2008
Richard Herring wrote:
>> Care to enlighten me, for one? I'm curious. Assuming he has set n
>> to 4 first and should synchronize n with the max value for j, and
>> should probably link the size of the array construction to that with a
>> const/variable,

> That's three assumptions already


Yeah, I know... I sorta objected first, then discovered one issue after
another *g* But none that would actually make the code not work if
treated properly. So I thought maybe I was missing something.

>> I currently see no other problems...

> Until he decides to switch from int to some user-defined type that isn't
> POD...

What does POD mean?

Do you mean some type that'll only store pointers to it's data in the
array, or some type where sizeof (type) doesn't yield the correct size?

Best Regards,

Lars
 
Reply With Quote
 
Richard Herring
Guest
Posts: n/a
 
      02-20-2008
In message <(E-Mail Removed)>, Lars Uffmann
<(E-Mail Removed)> writes
>Richard Herring wrote:
>>> Care to enlighten me, for one? I'm curious. Assuming he has set n
>>>to 4 first and should synchronize n with the max value for j, and
>>>should probably link the size of the array construction to that with
>>>a const/variable,

>> That's three assumptions already

>
>Yeah, I know... I sorta objected first, then discovered one issue after
>another *g* But none that would actually make the code not work if
>treated properly. So I thought maybe I was missing something.
>
>>> I currently see no other problems...

>> Until he decides to switch from int to some user-defined type that
>>isn't POD...

>What does POD mean?


Plain Old Data, though on looking more closely what I meant isn't
exactly what the standard defines as POD.
>
>Do you mean some type that'll only store pointers to it's data in the
>array, or some type where sizeof (type) doesn't yield the correct size?


I meant some type where all-bits-zero doesn't equate to having value
zero, or whose constructor actually needs to do something.

--
Richard Herring
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: "memset" vs "= {0}"...Are they equivalent if your initializing variables? C++ 1 09-23-2004 02:03 PM
Re: "memset" vs "= {0}"...Are they equivalent if your initializing variables? C++ 0 09-23-2004 01:28 PM
"memset" vs "= {0}"...Are they equivalent if your initializing variables? Nollie@runtime.com C++ 17 09-22-2004 06:06 PM
memset vs fill and iterators vs pointers Joe C C++ 5 08-24-2004 11:51 AM
2 questions: speed of memset() and pointer to multi-arrays k-man C++ 4 12-18-2003 08:52 PM



Advertisments