Array initialization

[Jo Siffert]

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

[Karl Heinz Buchegger]

Jo Siffert wrote:

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?
Yes.

Thanks,
Jo

--
Karl Heinz Buchegger
kb******@gascad .at

[JKop]

Jo Siffert posted:

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

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

memset(pArr,0,s izeof(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

[Karl Heinz Buchegger]

JKop wrote:

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

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

delete [] &pArr;

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
kb******@gascad .at

[Mats Weber]

In article <b8************ **************@ posting.google. com>,
jo********@gmx. net (Jo Siffert) wrote:

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

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

[Andrey Tarasevich]

JKop wrote:

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

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

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

delete [] &pArr;
Some-one may reply to this and say that setting padding bits to 0 is
undefined behaviour.
...

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

[JKop]

Andrey Tarasevich posted:

JKop wrote:

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

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

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

delete [] &pArr;
Some-one may reply to this and say that setting padding bits to 0 is
undefined behaviour.
...

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.

-JKop

[Karl Heinz Buchegger]

JKop wrote:

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.

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
kb******@gascad .at

[JKop]

Karl Heinz Buchegger posted:

JKop wrote:

> 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.

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.

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

[Karl Heinz Buchegger]

JKop wrote:

Karl Heinz Buchegger posted:

JKop wrote:

> 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.
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.

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

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.

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?

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
kb******@gascad .at