Array initialization

Hi,

I have an array like
Foo **ppArr = new Foo*[ size ];

I would like to check if the array holds a pointer to an object at a
certain index using something like
if ( ppArr[ idx ] == NULL ) { ... }

However, this statement always evaluates to false, as ppArr[ idx ]
always has a value of 0xcdcdcdcd instead of NULL (using VC++ 7).
Do I have to set all fields explicitly to NULL (using something like
UNIX's bzero()) to get this to work?

Thanks,
Jo

Jo Siffert wrote:[color=blue]
>
> Hi,
>
> I have an array like
> Foo **ppArr = new Foo*[ size ];
>
> I would like to check if the array holds a pointer to an object at a
> certain index using something like
> if ( ppArr[ idx ] == NULL ) { ... }
>
> However, this statement always evaluates to false, as ppArr[ idx ]
> always has a value of 0xcdcdcdcd instead of NULL (using VC++ 7).
> Do I have to set all fields explicitly to NULL (using something like
> UNIX's bzero()) to get this to work?[/color]

Yes.
[color=blue]
>
> Thanks,
> Jo[/color]


--
Karl Heinz Buchegger
kbuchegg@gascad.at

Jo Siffert posted:
[color=blue]
> Hi,
>
> I have an array like
> Foo **ppArr = new Foo*[ size ];
>
> I would like to check if the array holds a pointer to an object at a
> certain index using something like
> if ( ppArr[ idx ] == NULL ) { ... }
>
> However, this statement always evaluates to false, as ppArr[ idx ]
> always has a value of 0xcdcdcdcd instead of NULL (using VC++ 7).
> Do I have to set all fields explicitly to NULL (using something like
> UNIX's bzero()) to get this to work?
>
> Thanks,
> Jo[/color]

Foo* &pArr = *(new Foo*[size]);

memset(pArr,0,sizeof(Foo*[size]));

delete [] &pArr;


Some-one may reply to this and say that setting padding bits to 0 is
undefined behaviour.

[Insert quote from Standard here]

-JKop

JKop wrote:[color=blue]
>
>
> Foo* &pArr = *(new Foo*[size]);
>
> memset(pArr,0,sizeof(Foo*[size]));
>
> delete [] &pArr;
>[/color]

I know that you have become a newborn fan of references, but in the
above the reference doesn't buy you anthing except adding
confusion. If you do dynamic allocation, catch the pointer as
what it is: a pointer.

Foo** pArr = new Foo* [ size ];
....
delete [] pArr;

This also will correct the problem you have when doing:

Foo* &pArr = *(new Foo*[size]);
pArr[0] = NULL;
delete [] &pArr;

The assignment
pArr[0] = NULL;
does *not* do what most programmers would expect it to do:
set the 0-th pointer to NULL. Instead it tries to assign NULL
to the object pointed to by the 0-th pointer.

--
Karl Heinz Buchegger
kbuchegg@gascad.at

In article <b859be29.0406220303.14bfbd41@posting.google.com >,
jo.siffert@gmx.net (Jo Siffert) wrote:
[color=blue]
>I have an array like
> Foo **ppArr = new Foo*[ size ];[/color]

Use vector<Foo*> and all problems brought up in the discussion go away.

JKop wrote:[color=blue][color=green]
>> I have an array like
>> Foo **ppArr = new Foo*[ size ];
>>
>> I would like to check if the array holds a pointer to an object at a
>> certain index using something like
>> if ( ppArr[ idx ] == NULL ) { ... }
>>
>> However, this statement always evaluates to false, as ppArr[ idx ]
>> always has a value of 0xcdcdcdcd instead of NULL (using VC++ 7).
>> Do I have to set all fields explicitly to NULL (using something like
>> UNIX's bzero()) to get this to work?
>>
>> Thanks,
>> Jo[/color]
>
> Foo* &pArr = *(new Foo*[size]);
>
> memset(pArr,0,sizeof(Foo*[size]));
>
> delete [] &pArr;
>
>
> Some-one may reply to this and say that setting padding bits to 0 is
> undefined behaviour.
> ...[/color]

More than that. Setting non-padding (value-forming) bits of a pointer to
0 doesn't necessarily produce the null-pointer value of corresponding
type. In other words, it is not guaranteed that elements of the array
will compare equal to 'NULL' after that 'memset'.

--
Best regards,
Andrey Tarasevich

Andrey Tarasevich posted:
[color=blue]
> JKop wrote:[color=green][color=darkred]
>>> I have an array like
>>> Foo **ppArr = new Foo*[ size ];
>>>
>>> I would like to check if the array holds a pointer to an object at a
>>> certain index using something like
>>> if ( ppArr[ idx ] == NULL ) { ... }
>>>
>>> However, this statement always evaluates to false, as ppArr[ idx ]
>>> always has a value of 0xcdcdcdcd instead of NULL (using VC++ 7).
>>> Do I have to set all fields explicitly to NULL (using something like
>>> UNIX's bzero()) to get this to work?
>>>
>>> Thanks,
>>> Jo[/color]
>>
>> Foo* &pArr = *(new Foo*[size]);
>>
>> memset(pArr,0,sizeof(Foo*[size]));
>>
>> delete [] &pArr;
>>
>>
>> Some-one may reply to this and say that setting padding bits to 0 is
>> undefined behaviour.
>> ...[/color]
>
> More than that. Setting non-padding (value-forming) bits of a pointer to
> 0 doesn't necessarily produce the null-pointer value of corresponding
> type. In other words, it is not guaranteed that elements of the array
> will compare equal to 'NULL' after that 'memset'.
>[/color]

This I don't understand.

-JKop

JKop wrote:[color=blue]
>[color=green]
> > More than that. Setting non-padding (value-forming) bits of a pointer to
> > 0 doesn't necessarily produce the null-pointer value of corresponding
> > type. In other words, it is not guaranteed that elements of the array
> > will compare equal to 'NULL' after that 'memset'.
> >[/color]
>
> This I don't understand.[/color]

It's pretty simple once you know it.

When setting a pointer to 'doesn't point anywhere' we write

int* pPtr = 0;

Even if the above looks like assigning the bit pattern for 0 to a pointer
variable, it need not be so. A specific platform might use a completely
different bit pattern for describing: pointer to nowhere. Well, even if
a specific platform does that, we still write pPtr = 0, and the compiler
has to replace 0 with the bit pattern used at that platform.

Pointer_value_0 != bit_pattern_for_0

The compiler can do this, because it knows about pointers and this
special case. But memset() doesn't.


--
Karl Heinz Buchegger
kbuchegg@gascad.at

Karl Heinz Buchegger posted:
[color=blue]
> JKop wrote:[color=green]
>>[color=darkred]
>> > More than that. Setting non-padding (value-forming) bits of a
>> > pointer to 0 doesn't necessarily produce the null-pointer value of
>> > corresponding type. In other words, it is not guaranteed that
>> > elements of the array will compare equal to 'NULL' after that
>> > 'memset'.
>> >[/color]
>>
>> This I don't understand.[/color]
>
> It's pretty simple once you know it.
>
> When setting a pointer to 'doesn't point anywhere' we write
>
> int* pPtr = 0;
>
> Even if the above looks like assigning the bit pattern for 0 to a
> pointer variable, it need not be so. A specific platform might use a
> completely different bit pattern for describing: pointer to nowhere.
> Well, even if a specific platform does that, we still write pPtr = 0,
> and the compiler has to replace 0 with the bit pattern used at that
> platform.
>
> Pointer_value_0 != bit_pattern_for_0
>
> The compiler can do this, because it knows about pointers and this
> special case. But memset() doesn't.[/color]

Interesting! I'm assuming this is in the Standard, yes?


Similarly, if you write:

int* jk; //Global variable

It may get 0, or it may get whatever is supposed to be a NULL pointer. That
right?


-JKop

JKop wrote:[color=blue]
>
> Karl Heinz Buchegger posted:
>[color=green]
> > JKop wrote:[color=darkred]
> >>
> >> > More than that. Setting non-padding (value-forming) bits of a
> >> > pointer to 0 doesn't necessarily produce the null-pointer value of
> >> > corresponding type. In other words, it is not guaranteed that
> >> > elements of the array will compare equal to 'NULL' after that
> >> > 'memset'.
> >> >
> >>
> >> This I don't understand.[/color]
> >
> > It's pretty simple once you know it.
> >
> > When setting a pointer to 'doesn't point anywhere' we write
> >
> > int* pPtr = 0;
> >
> > Even if the above looks like assigning the bit pattern for 0 to a
> > pointer variable, it need not be so. A specific platform might use a
> > completely different bit pattern for describing: pointer to nowhere.
> > Well, even if a specific platform does that, we still write pPtr = 0,
> > and the compiler has to replace 0 with the bit pattern used at that
> > platform.
> >
> > Pointer_value_0 != bit_pattern_for_0
> >
> > The compiler can do this, because it knows about pointers and this
> > special case. But memset() doesn't.[/color]
>
> Interesting! I'm assuming this is in the Standard, yes?[/color]

Yes. of course
But it's not written down that way. It follows from some rules that
turn around null pointer values, null pointer constants and their
required behaviour.
[color=blue]
>
> Similarly, if you write:
>
> int* jk; //Global variable
>
> It may get 0, or it may get whatever is supposed to be a NULL pointer. That
> right?[/color]

It may be everything. No initialization -> undefined (except in static
cases. God how I hate those exceptions everywhere:

static int i;

i has a value of 0. Even without initialization. It's a leftover from C)

--
Karl Heinz Buchegger
kbuchegg@gascad.at

Karl Heinz Buchegger posted:
[color=blue]
> It may be everything. No initialization -> undefined (except in static
> cases. God how I hate those exceptions everywhere:
>
> static int i;
>
> i has a value of 0. Even without initialization. It's a leftover from
> C)[/color]


int* jk;


Mine was a global variable. Global variables get initialized to 0, no?

If so, does a global pointer get initialized to NULL, which may or may not
be 0?


-JKop

JKop wrote:[color=blue]
>
> Karl Heinz Buchegger posted:
>[color=green]
> > It may be everything. No initialization -> undefined (except in static
> > cases. God how I hate those exceptions everywhere:
> >
> > static int i;
> >
> > i has a value of 0. Even without initialization. It's a leftover from
> > C)[/color]
>
> int* jk;
>
> Mine was a global variable. Global variables get initialized to 0, no?[/color]

Aehm. ... thinking ... I think the answer is yes. (Not so sure
if I have mixed up static with global variables right now)

I write explicite initializations everywhere and don't have to remember
all those exception rules :-)
[color=blue]
>
> If so, does a global pointer get initialized to NULL, which may or may not
> be 0?[/color]

yes.

Same with double.
Noboby says that the bit pattern for 0.0 equals all bits zero.

--
Karl Heinz Buchegger
kbuchegg@gascad.at

JKop wrote:[color=blue]
> Karl Heinz Buchegger posted:
>[color=green]
>> It may be everything. No initialization -> undefined (except in static
>> cases. God how I hate those exceptions everywhere:
>>
>> static int i;
>>
>> i has a value of 0. Even without initialization. It's a leftover from
>> C)[/color]
>
>
> int* jk;
>
>
> Mine was a global variable. Global variables get initialized to 0, no?
>
> If so, does a global pointer get initialized to NULL, which may or may not
> be 0?
> ...[/color]

Hmm... You are a bit confused. When it comes to pointer initialization,
NULL acts the same way as literal '0' (or, more precisely, an integral
constant expression that evaluates to zero). So in this context it is
safe to say that NULL _is_ 0.

A pointer of type 'int*' with static storage duration gets implicitly
initialized to null-pointer value (NPV) of type 'int*'. This is not
exactly what NULL is. NULL is universal null-pointer constant (NPC)
(just like literal '0', for example). When NPC gets converted to certain
pointer type 'T*', it turns into NPV of that type. Different pointer
types might use completely different representations for their NPVs.
NPVs are not required to be represented by "all-zeroes" bit pattern.
That's why 'memset' is not guaranteed to produce NPVs in the original
example.

--
Best regards,
Andrey Tarasevich