Hi folks,
Frank Heckenbach wrote:
Yes. Linked lists are both possible and easy, with your "store" and "reference" pointer idea, provided there is a standard (ie. inbuilt) "procedure" to swap two "store" pointers. I think that's all you need to overcome the problem with linked lists.
Sorry, but to me it seems a way to solve this particular situation that occurs with simple linked lists (as you described in a previous mail) where you have an exact overview what is going on (and therefore don't need the whole concept at all -- *because* you know exactly what's going on, and could just do things correctly with normal pointers).
I agree with Frank here -- the swap routine would just be a difficult solution for a self-made problem. For linked lists, a "normal" pointer without restrictions is probably the best solution.
Maybe I'm just playing devil's advocate here, but I really don't see any advantage of the concept yet (except maybe in rather special situations such as those that Markus has in mind with his collections IIUIC) ...
They're quite common situations, at least in object-oriented programming: You often have some object stored in, e.g., a list, referenced from three other lists with other sorting criteria, plus two trees sorting the object into different hierarchies, plus a hashtable of completely other objects referencing the first one in a bunch of associations etc. etc. etc.. Keeping the overview of who is when allowed to destroy which object often becomes an act of complex logics. It is either a quite common pattern to keep track of your "stores" and "references". (A most common example are existence- dependent or -independent associations in UML.) My suggestion was to make this pattern an inherent part of the compiler.
Bye
Markus