[fpc-devel] NoGlobals branch

Hans-Peter Diettrich DrDiettrich1 at aol.com
Wed Aug 11 16:09:47 CEST 2010


After the problems with the global variables, I started another branch 
for removing global variables and fixing compiler "states".

In the NoGlobals branch I already could make the scanner/parser a child 
object, owned by the module. It is not yet clear, however, whether the 
parser or entire modules can be destroyed before the end of compilation 
- if memory requirements are of interest at all.

Unfortunately I couldn't merge this working solution for the 
compiler/parser startup and shutdown into the OO_rewrite branch, so that 
I'll have to continue with this new branch.

Now it becomes easier to assign further globals and procedures to 
specific classes, so that finally every parser can work in its own 
thread. The current_module becomes the first, and hopefully only, 
candidate for a threadvar. For use in other applications a compiler 
class/object could be constructed as well, and back-end classes, of course.

Since not all currently global variables can be moved into their 
"natural" (owning...) classes, without causing circular references, I 
started to replace e.g. current_scanner by a property.

Nonetheless many assumptions have to be corrected or specified, like a 
compile_level doesn't make sense in a threaded compilation. I already 
tried to replace that counter by a comparison 
current_module=main_module, but this seems not to work properly. I'll 
try module.loaded_from=nil in the next round.

I also found an simple workaround for the TImplementedInterfaces 
problems (getcopy), that can be moved into the trunk immediately.

DoDi




More information about the fpc-devel mailing list