pointers (was: gcc-3+)
markus at gerwinski.de
Wed Feb 20 13:24:38 CET 2002
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.
More information about the Gpc