[fpc-devel] Status report for "class helpers"
Hans-Peter Diettrich
DrDiettrich1 at aol.com
Mon Jan 31 02:06:35 CET 2011
Jonas Maebe schrieb:
> An alternative solution could be to add a hashtable (tfphaslist) to
> tmodule whose entries are hashed on the qualified class names
> (unit$classname, since different units can contain classes with the
> same name). The value of such an entry would a tfpobjectlist of class
> helpers, with the last entry the one that is actually used. This list
> has to be updated whenever a symtablestack.push/pop is performed (you
> would probably have to wrap those calls, since the symtablestack
> itself is a fairly low level thing and I don't think it is supposed
> to know anything about tobjectdefs).
IIRC a class symtable is pushed onto the symtable stack, whenever a
qualifier is encountered (e.g. "TFoo."). Regardless of the
implementation, this makes the symbol search start in TFoo and continue
in its ancestors, before the remainder of the stack is searched. It
should be possible to extend that mechanism, adding eventual class
helpers to the search order.
Removal of such a qualified scope, with all contained ancestors, also
must have been implemented already, and should not deserve much changing.
> Of course, this won't be free either since you have to scan all
> pushed symtables for class helpers, and when popping them you have to
> go through all hashtable items to remove the appropriate ones. I
> don't know whether overall it will be faster or slower than your
> current approach.
Is the hashtable *really* rebuilt with every push and pop of another
symtable? It would be much easier to have a hashtable per symtable, that
deserves no further modifications. When all hashtables use the same hash
algorithm, a hash value must be computed only once, and then can be used
for lookup in every STB on the stack.
DoDi
More information about the fpc-devel
mailing list