Please see below ...
Joe.
-----Original Message----- From: Markus Gerwinski [SMTP:markus@gerwinski.de] Sent: Tuesday, February 19, 2002 6:10 AM To: da Silva, Joe Cc: 'gpc@gnu.de' Subject: Re: gcc-3+
Hi folks,
da Silva, Joe wrote:
FWIW, I see the "store pointer" being what you are describing here as the "other pointer" (I think). It points to the real data, and the "reference pointers" just point to it (the "store pointer").
That was my idea, yes... but after re-thinking, I now found an unintentional side effect: This would cause the reference pointer to _always_ point to the data of the store pointer, even if you dispose and re-new the store; the command sequence
new ( store ); ... reference:= store; (* set reference^ to store^ *) ... dispose ( store ); (* set reference to nil *) ... new ( store ); (* set reference^ to store^ ... without a command *)
[Joe da Silva]
No, the last statement cannot result in a new assignment for the reference pointer. That's just unacceptable. That's why Frank was saying you needed "double pointers", so that you could specifically set the reference pointer to "nil" when you disposed it's corresponding store pointer. So, the subsequent "new" statement would not re-assign the reference pointer - if that's what you (ie. the programmer) want, you assign it explicitly after the "new" statement.
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;-).
would then contain a new trap to tangle up the logic of the program. The implicit handling of a store/reference concept doing exactly what it is supposed to do (hooking the reference to the _data_, not to its store) would, as Frank said, really be more complicated, I fear.
Bye
Markus
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