Hi folks,
Frank Heckenbach wrote:
This is usually not, what you do... is it? If the pointer p1 is the one used to allocate p1^, and it is also referenced by p2..pn, you normally take care to use p1 again to deallocate, don't you?
I don't think so. It's not uncommon, e.g., for a function to allocate and return (copy) something in a pointer, or to pass (copy) a pointer to a procedure to clean it up and dispose it. Or to allocate a pointer in a local variable, do something with it, then put it in a global list from where it's later disposed, etc.
For these purposes, you still could pass a store pointer as a parameter. (Nobody prevents you from defining "Procedure foo ( bar: store )", since you never explicitly write "bar:= baz" or something.) Anyway, Maurice already kept me on the case of the linked list (see parallel mail), where you really can't avoid using a pointer as both, store and reference; so I don't insist any longer. Replacing the pointer by store and reference would without doubt be a bad idea. But I still think it could be a useful supplement.
With double pointers I mean: When you allocate some memory, you allocate another pointer to it, and let the real pointers point to that. So if you dispose of the memory, you set the other pointer to nil (or something), and you don't have to iterate over all reference pointers. The problem then would be that you can never dispose of the other pointer if you don't keep track of all existing reference pointers, so it's not a good solution.
I'm not quite sure, if I understand your "other" pointer right. Do you mean something like this?
var s: store; r: reference;
... new ( s ); r:= s; (* This one implicitly creates a pointer pr *) ... (* connected to s, pointing to r *) ... dispose ( s ); (* must find pr, too, set r to nil and destroy pr *)
Is that the structure you mean?
Bye
Markus