Hi folks,
Frank Heckenbach wrote:
Though I'm not sure why the distinction between store and reference pointers is necessary. Why not make all pointers the same, and when one pointer to an object is disposed of, all the other ones are invalidated?
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?
If so, you _are_ implicitly working with "store" and "reference" pointers. Making this an explicit naming within the programming language would IMO make the language more "speaking". It would enforce "clear responsibilities" within the program: Only the pointer that created a piece of memory may destroy it.
If the restrictions are like this:
- store pointers may _only_ "new" or "dispose", but never be set to the value of another pointer. Trying to "new" an already set store pointer causes a runtime error.
- reference pointers may _only_ be set to the value of another pointer, but never be "new"ed or "dispose"d.
... then memory leaks are made impossible (you just _can't_ allocate a pointer and then set somewhere else), and accidentally disposing of some data still needed by a bunch of other pointers becomes at least less likely (reference p42 just isn't able to dispose of p1).
What I don't understand about your story is
(1) how do you check if you can dereference the reference pointer. (e.g. what if the store pointer has been killed) (2) If you do that by invalidating the reference pointers, you'd need to have to be able to find the refernece pointers for a given store pointer. The situation then already approximates equals a primitive GC system . This all depends on if the store and reference pointers are all invalidated all at once, and how you deallocate.