Array of pointers. How to check index without failure?

>stuff... crash.

Hello, I have a static array of pointers to custom objects: MyObject *
aMyObjects[500]
>
How can i can check if an index has a pointer stored? Assuming without
checking leads to crashes if no pointer is there: aMyObjects[0]->
Any help with this would be much appreciated.

Hello, I have a static array of pointers to custom objects: MyObject *
aMyObjects[500]
>
How can i can check if an index has a pointer stored? Assuming without
checking leads to crashes if no pointer is there: aMyObjects[0]->
Any help with this would be much appreciated.

Lorn <efoda5446@yahoo.comwrote:
>>
Set the values to 0 or NULL. Check to see if the value is 0 before
dereferencing it.

Daniel T. wrote:>
To protect against dangling pointers, a better approach would be to use
an extra 'initialized' bit for each pointer set to 1/0 appropriately.

On Thu, 02 Aug 2007 17:21:42 -0700, Vaibhav Nivargi wrote:>>
How would that help? You'ld have to manually set/clear the initialized bit
whenever the status changed, and I would have thought that's no easier or
harder than setting the pointer to 0.

One other option that IBM used in it's version of the Xerces library
was to
surround all object references with a "try-catch" block and then they
surpress
the exception when they hit an invalid pointer. This works, but it's a
real performance
hog. An XML parser that I had to maintain (without being allowed to
change it) spent
nearly 50% of its runtime in these exception handlers.

On Aug 2, 8:41 pm, I V <ivle...@gmail.comwrote:

Be careful using the "if(p)" syntax; it does an integer
comparison on the pointer which isn't valid on all platforms.

Most compilers have an option to prefill any static memory
block to zeros;

use it if it is available and then
use
"if( ((X*)p) != ((X*)0))". It's a little harder for you to write, but
it
guarantees a valid comparision.

One other option that IBM used in it's version of the Xerces
library was to surround all object references with a
"try-catch" block and then they surpress the exception when
they hit an invalid pointer. This works, but it's a real
performance hog. An XML parser that I had to maintain (without
being allowed to change it) spent nearly 50% of its runtime in
these exception handlers.

On Aug 3, 5:38 am, Jeff <jeff.griff...@gmail.comwrote:
>>
No it doesn't. The condition in an if must have type bool.
There is an implicit conversion of pointer to bool, which is
basically the equivalent of "p != NULL". Code like "if (p)" may
be unreadable, and it's not the sort of thing you'd ever see in
well written C++, but it is perfectly legal and well defined.
>>
I've never heard of a compiler with such an *option*. The
language standard requires that all objects with static storage
duration be "zero initialize" before the program starts. "Zero
initialized" means, basically, that each low level type is
initialized as if 0 were assigned to it. Again, there is a
special conversion, so that the integer value 0 converts to a
null pointer; even if null pointers aren't all bits 0, a pointer
with static storage duration is guaranteed to be initialized
with a null pointer value. (The one exception is in a union.
Only the first element of a union is zero initialized.)
>>
You don't have to get carried away:
if ( p == NULL )
or
if ( p == 0 )
work perfectly well, and are perfectly readable.
>>
I doubt that it was written in C++. In C++, dereferencing a
null pointer results in undefined behavior; on typical desktop
machines, it will cause a fatal program crash (core dump, in
Unix-speak).
>
Of course, since the behavior is undefined, an implementation is
free to do whatever it wants, including raise an exception.
IMHO, that would not be very good from a QoI point of view, but
it would certainly be conforming (as would be formatting your
hard disk).
>
--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

>
No it doesn't. The condition in an if must have type bool.
There is an implicit conversion of pointer to bool, which is
basically the equivalent of "p != NULL". Code like "if (p)" may
be unreadable, and it's not the sort of thing you'd ever see in
well written C++, but it is perfectly legal and well defined.

James Kanze wrote:
...>
if (p) *IS* readable. There is nothing ambiguous, unclear or not "well
written" about it other than it's missing one of the silliest standard
macros since the beginning C compared to if (p != NULL).

Gianni Mariani <gi3nospam@mariani.wswrote in news:46b3a088$0$31411
$5a62ac22@per-qv1-newsreader-01.iinet.net.au:
>>
I disagree. I prefer the explicit test against NULL. (I'd prefer it even
more if they standardize on a keyword nulptr). I dislike testing implicit
conversions to bool, so the only time I write "if (p)" is only if p is a
bool. If it is anything else, I'll write out the full test; "if (p != 0)"
for example.

Gianni Mariani <gi3nospam@mariani.wswrote in news:46b3a088$0$31411
$5a62ac22@per-qv1-newsreader-01.iinet.net.au:
>>
I disagree. I prefer the explicit test against NULL. (I'd prefer it even
more if they standardize on a keyword nulptr). I dislike testing implicit
conversions to bool, so the only time I write "if (p)" is only if p is a
bool. If it is anything else, I'll write out the full test; "if (p != 0)"
for example.

"if ( thing )" has been part of C and C++ and Perl and a number of
languages.

On Aug 4, 2:47 am, Gianni Mariani <gi3nos...@mariani.wswrote:>
That doesn't make it good engineering. Say what you mean, and
mean what you say. Every good company I've seen or heard about
has an absolute rule that requires the explicit test, no
exceptions allowed.