Markus Gerwinski wrote:
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.)
I don't understand. Passing a value parameter is almost the same as an assignment. I.e., if the procedure disposes of the store pointer parameter, the also store pointer in the caller gets invalid which should not happen.
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?
That was my first idea. The second one (quoted here) would be:
New (s); { internally: New (s); New (s^); } Foo (s^); { internally: Foo (s^^); } r := s; { internally: r := s; } Dispose (s); { internally: Dispose (s^); s^ := nil; } Foo (r^); { now r^ = nil, so error }
But you could never Dispose (s) (internally) because then r would be dangling, so you have a kind of memory leak.
Hmm, right. Here you got me. For linked-list maintenance etc., we need the free play with pointers. (Awkward... I missed the trivial case by modeling the complex ones...)
Apparently we have rather different usages in mind. For my (and GPC/GCC's) purposes, linked lists are a basic building block, i.e., almost everything is a superset of linked lists (e.g., doubly linked lists, trees, graphs, ...).
Frank