Re: Test if memory pointer is valid?

"Paul E. Schoen" <pstech@xxxxxxxxx> wrote in message
news:11tjgsk1ickpkd4@xxxxxxxxxxxxxxxxxxxxx
> "Richard A. DeVenezia" <rdevenezia@xxxxxxxxxxxx> wrote in message
> news:43tfb0F1npa5qU1@xxxxxxxxxxxxxxxxx

>> Is there a way or technique for knowing if a pointer points to
>> memory that has been freed ?

I cringed and smirked at the same time when reading Rob's answer. It's
_so_ true, and _so_ not what you wanted to hear.

The basic distinction is between "owning references" and "aliases".
An owning reference is allowed to free the object, and should trigger
a step of invalidating all other references. And no help is forthcoming
with that; you have to do it yourself. Because...


> [...] at the basic level, a pointer is just a memory address that
> contains the memory address of some data, which could be anything
> from a single byte to an array, structure, or object, which may in
> turn contain other pointers.

....all pointers look alike, and quack alike.


> If the pointer is nil, or all zeroes, it does not point to anything.
> When it is initialized, it should contain the address of memory which
> has been allocated for the size of the data type it represents. Thus,
> if it is set to nil when it is freed, it can be checked for validity.

This is the simplest implementation of pointers, but not the only one
possible. I've heard some rumours that on the AS/400 (when it was still
called that), language-level pointers are more like descriptors, with
lots of extra information. That way, you could for example have a
procedure pointer that includes, in the pointer value itself, information
about the procedure's signature.

Also, while it is a common convention that all-zeroes is used for the
null pointer, it's not the only possible representation. All ones would
work just as well, for example. And in an extensively annotated pointer
like the example above, a single bit somewhere might be enough.


> My problem is that I don't know why a second variable should be set to
> point to the same block of memory. I can possibly understand setting a
> pointer to the original pointer, and perhaps interpreting the memory
> space in a different way, using a typecast.

Do you realise what happens when you drop a control on a form in the
IDE? If you run that program, during form loading that control will be
recreated and a reference to it left in the published field maintained
by the IDE.

And the form will be set as its Owner. That results in the control
storing a reference to the owner in its Owner property, and the owner
adding a reference to the control in its Components[] property.

And the form, or a panel or tab*** or whatever, will be set as its
Parent. That results in the Control storing a reference to the parent
in its Parent property, and the parent adding a reference to the control
in its Controls[] property.

That's three references so far.

Have you ever used the same event handler for several components? Event
handlers aren't objects, but it's a prime example of a case where many
pointers may reference the same destination. Even if you should insist
on "setting a pointer to the original pointer", all those events are
created equal and you couldn't argue which one is the original.

Groetjes,
Maarten Wiltink


.