[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