«

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.

or can I new a piece of memory and set it to zero in the mean time?

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.

On 20 Feb., 13:28, thomas <FreshTho...@gmail.com> 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

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

On Wed, 20 Feb 2008 04:35:26 -0800, peter koch wrote:

> On 20 Feb., 13:28, thomas <FreshTho...@gmail.com> 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

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

In message <>, Lars Uffmann
<> 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

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

In message <>, Lars Uffmann
<> 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