You take things too seriously, Frank. The wink in reference to GC was a clue that you shouldn't have ... <G>
One of the key advantages of Pascal over more primitive languages, and one of several reasons it is much less bug prone, is that it imposes discipline on the program. IMHO, GC is contrary to that philosophy and not appropriate to Pascal (which is what we are discussing, since we have already established that the GPC compiler needs to use GC to be compatible with GCC-3).
What I was thinking (in the previous message), was that if "double pointers" were not employed for this "store" and "reference" pointer suggestion, then it would be necessary to search the "reference" pointers to find which ones were no longer valid. And I was also thinking that GC must also do similar searching of pointers, but instead to find what memory blocks were no longer in use. So I reasoned that although searching the "reference" pointers would be relatively inefficient (compared to using "double pointers"), it should be comparable to GC, so I was merely putting this in perspective.
While on this topic (you'll note that I had changed the subject heading, since we really aren't talking about the original GCC-3 issue any more), I had a thought that perhaps rather than setting any "reference" pointers to nil when their corresponding "store" pointer was disposed, perhaps this should really result in a run-time error. That is, you cannot dispose a "store" pointer if it has any "reference" pointers associated with it. This would be better than later in the code, trying to dereference a "reference" pointer, then trying to figure out why/when it became invalid.
Joe.
-----Original Message----- From: Frank Heckenbach [SMTP:frank@g-n-u.de] Sent: Tuesday, February 19, 2002 6:06 PM To: gpc@gnu.de Subject: Re: pointers (was: gcc-3+)
da Silva, Joe wrote:
You could also search the reference pointers when disposing a store pointer, to find out which of these are affected, but that would be inefficient (like GC;-).
It's always easy to make such claims, but I've yet to see a solution (for the general case) that is more efficient, considering any hidden costs?
BTW, have you studied GC algorithms? I haven't, but I've see that some research has done in this area and a good GC algorithm is quite a bit better than an implementation I'd come up with if I tried it naively ...
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html