Re: Test if memory pointer is valid?
- From: "Bruce Roberts" <dontsendtober@xxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 27 Jan 2006 17:19:50 -0500
"Paul E. Schoen" <pstech@xxxxxxxxx> wrote in message
news:11tjgsk1ickpkd4@xxxxxxxxxxxxxxxxxxxxx
> 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. This may be similar to the "C" concept
> of a
> Union, in which several variable names all point to the same memory, but
> are
> interpreted by the compiler in different ways. However, I think each
> variable is compiled as the same address, so if any one is Freed and made
> nil, a reference to any one is also nil.
Multiple references are extremely common. Consider forms in a Delphi
application, there are at least five (IIRC) references to the main form
instance. There are typically 4 references to any other form instance. Add
to that number the count of every control on the form (Owner) and
potentially double it (Parent). Every control on a form has at least two
references, and controls embedded in sub-controls have at least one more
reference, as do grouping controls. And I haven't even gotten into
application code.
Consider a typical data table with multiple indexes. Do you not expect that
each index will contain a reference to every record? You may not consiously
think about using multiple references, but I supect that you use them all
the time.
> I can't think of any reason to have two separate pointers to the same
> address, but it must be common, as I have been informed previously about
> multiple references. I can see setting a new pointer initially to the
> address of the beginning of an array, for example, and then incrementing
> the
> pointer to address subsequent elements, but that would usually be done
> inside a function, where the new pointer would go out of scope at the end
> of
> the function and be reinitialized if it is called again. I would like to
> see
> a specific example where it is necessary to have multiple references such
> as
> this where it would be necessary to check for it having been freed.
In a well designed application one should not have to perform such
checking. The design itself should be structured to insure that references
are only ever made when valid.
Designing with multiple references allows for a great degree of flexibility
and code isolation. A VAR parameter is (and with some caveates value
parameters are), in fact, simple examples of multiple references. Look how
useful they can be.
> Possibly, I can see where two objects on a form, perhaps, might reference
> fields in each other, but unless the object itself had been freed, the
> reference should be valid, and you can always check to see if the object
> is
> not nil.
There are situations, however, in which the item being referenced has a
lifetime that may not be the same as some of its references.
> If there is such a reason, would it be possible to assign a pointer to
> the
> original pointer, and then use dereferencing to determine if the original
> pointer was nil and therefore free, or otherwise safe to use?
A cumbersome architecture. It is inherently limiting because references are
no longer orthogonal, i.e. code must somehow distinguish between a
principal reference and a sub-reference.
.
- References:
- Test if memory pointer is valid?
- From: Richard A. DeVenezia
- Re: Test if memory pointer is valid?
- From: Paul E. Schoen
- Test if memory pointer is valid?
- Prev by Date: Re: Event handlers...
- Next by Date: Re: Folding Editor
- Previous by thread: Re: Test if memory pointer is valid?
- Index(es):
Relevant Pages
|
