dispose: bug or feature?

Scott Moore samiam at moorecad.com
Tue Dec 11 18:26:04 CET 2007


Peter N Lewis wrote:
> It's not worth nit picking on the list further, but I wonder if...:
> 
>> dispose(q)
>> shall remove the identifying-value denoted by the expression q from the
>> pointer-type of q . It shall be an error if the identifying-value had
>> been created using the form new(p,c l , . . .,cn).
>>
>> ...
>>
>> NOTE -- The removal of an identifying-value from the pointer-type to
>> which it belongs renders the identified-variable inaccessible (see 
>> 6.5.4) and makes undefined all variables and functions that have that
>> value attributed (see 6.6.3.2 and 6.8.2.2).
> 
> 
> "identified-variable" refers to the content, not p per se?
> 
> Note how it makes the distinction of "identifying-value" (ie the 
> pointer?) and "identified-variable" (ie p^).
> 
> Thus p^ is inaccessible.
> 
> There is a reason I don't attempt to read standards!

It says "makes undefined all variables and functions that have that
value attributed", and the "value" the speaketh of is the
"identifying-value".

This is why I included the definition of:

new(p)
shall create a new variable that is totally-undefined, shall create a
new identifying-value of the pointer-type associated with p, that
identifies the new variable, and shall attribute this identifying-value
to the variable denoted by the variable-access p

Note "shall attribute this identifying-value to the variable denoted by
the variable-access p"

The double speak has a purpose, and the meaning covers several
storage management schemes, including references and recycling.

For reference systems, where the pointer contains not an address but
a logical key to the actual variable, the "identifying-value" becomes
undefined because its table entry becomes invalid. For recycling
systems, the actual pointer may be set invalid.

Its an important point, because it lets the implementor implement
advanced storage handling.

Scott Moore





More information about the Gpc mailing list