[fpc-devel] RIP NoGlobals

[Hans-Peter Diettrich]

Jonas Maebe schrieb:

> There are more things that prevent that, not in the least that almost 
> any source code error will result in lots of memory leaks from the 
> compiler.

IMO just such problems can be reduced by moving global variables into 
classes. When e.g. a single Compiler object holds the references to all 
other heap objects, an entire cleanup can be performed in the destructors.

This is where the Pascal "singleton" hack (units for classes) differs 
from true OOP, because units can not be "destroyed". The many 
constructors and destructors of such compiler singletons (InitCompiler, 
DoneCompiler...) should be callable (and actually be called) after every 
compilation.


>> For compiler development and debugging purposes it would be very nice, 
>> when all targets are covered in one compile.
> 
> It increases the compiler build time, which is not nice.

Building an compiler for all targets can be done in e.g. make fullcycle, 
or in an according .lpi, while the default compiler still can be built 
for only the specified target. As before, every target has to be 
included explicitly, by referencing its "root" unit.


> And I 
> personally, as a compiler developer and debugger, think it's very nice 
> that everything is cleanly separated and that it's not possible to have 
> accidental cross-target dependencies, which could result in changes in 
> the constants/types for one target to suddenly impact a completely 
> different target.

The target specific types etc. have to be encapsulated, so that they can 
not be used by accident. This is not hard to manage (still hard to 
implement ;-), because the conflicting target-specific units and types 
have to be renamed for "parallel" use. Since this disallows to use 
target specific types in general compiler code, proper virtualization is 
enforced by that renaming, so that many of your problems will disappear 
consequently :-)


> Until FPC is developed by perfect programmers that never make any 
> errors, I think that minimising the way in which things can get 
> entangled is the best way.

A good OOP language and development system shall not only *allow* for OO 
programming, it also should *encourage* the use of OOP. When compiler 
developers state that their OOP compiler is constructed in an non-OO 
way, for performance or other reasons, this IMO is only an excuse for 
not understanding the pros of OOP, or for bad use or implementation of 
the support for objects and related types (dynamic strings...).

It's possible that the use of OO features, together with spaghetti code, 
can result in a performance degradation. But OTOH performance can 
improve as well, when *all* (related) parts of a project cooperate by 
using OO features.

In detail I still doubt that the use of dynamic strings *everywhere* 
will really result in an much slower compiler - the opposite may be true 
as well. It's known that stringhandling in an OO way can result in poor 
performance (see .NET strings), due to clumsy overloading of the string 
operators - but such overhead can be reduced by using more compiler 
magics, instead of general overloading. Also arguments like "FillChar 
takes a long time", as an argument against using classes (InitInstance), 
IMO is only a misinterpretation of the profiling information - it might 
come as well from the page faults, that occur on the first access to new 
heap objects, and only becomes *visible* in the use of a common 
(FillChar...) procedure, while otherwise the page faults are added to 
arbitrary code, that accesses an heap object for the first time.

DoDi