Markus Gerwinski markus@gerwinski.de a dit :
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).
Gosh. How do you do with linked lists, a quite common situation I believe. If you append records only at the end of the list, you can use the last "next" pointer as a store pointer. But what do you do if you want to insert a new record in the middle of the list. Usually either: you keep the address of the next record in a temporary pointer and allocate the new record with the "next" pointer of the previous: invalid because you try to new an undisposed pointer. you allocate the new record with a "temporary" pointer (no problem up to that point, it will be a store pointer) and then insert it, playing with two "next" pointers: but the previous "next" goes from store to reference status. And you need to keep somewhere all "temporary" pointers which served you to allocate the elements ...
Maurice
Hi folks,
Maurice Lombardi wrote:
Gosh. How do you do with linked lists, a quite common situation I believe. If you append records only at the end of the list, you can use the last "next" pointer as a store pointer. But what do you do if you want to insert a new record in the middle of the list. Usually either: you keep the address of the next record in a temporary pointer and allocate the new record with the "next" pointer of the previous: invalid because you try to new an undisposed pointer. you allocate the new record with a "temporary" pointer (no problem up to that point, it will be a store pointer) and then insert it, playing with two "next" pointers: but the previous "next" goes from store to reference status. And you need to keep somewhere all "temporary" pointers which served you to allocate the elements ...
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...)
Bye
Markus
-
Markus Gerwinski -
Maurice Lombardi