[fpc-devel] "Friend" classes?
Marco van de Voort
marcov at stack.nl
Tue Mar 29 21:12:55 CEST 2005
> Marco van de Voort wrote:
> > > immediately contribute to the size of a compiled module, only when they
> > > are *used* in code modules.
> > That goes for all routines.
> I'm not sure what you mean. A global procedure, exported in the
> interface section of a unit, always must be be compiled.
> Only the linker can determine which procedures really are used in a
> project, and which ones can be omitted. A specific procedure can be used
> in one project, but can be unused in another project. Think of the
> standard units like System...
Yeah, but smartlinking/deadcodeelimination is a pretty standard feature.
> > > In comparison with C/C++, "uses" summarizes the #include of header files
> > > and the dependency checks of Make.
> > The important difference (in TP/Delphi/FPC) is that preprocessor state
> > doesn't follow USES statements.
> Do you mean that only one level of dependencies must be checked with
> "uses", whereas even the indirectly #included files must be checked for
You always have to do the #include. Always. Pre-compiled headers are
possible, not trivial, since it requires a comparison of the entire
preprocessor state to see if a header needs recompilation.
> > That allows the compiler to auto-find the compilation order..
> What's the importance of a compilation order?
It is something that doesn't come cheap.
> > The effect of units is that it is a lot safer (more guaranteed) and easier
> > to implement that precompiled header files, and auto-building is also a lot
> > easier (not requiring explicit manual compile order enforced)
> Again I don't understand what you mean (compile order???) :-(
Not recompiling the headers each time saves a lot of time.
> A C project doesn't require any compilation order, every module can be
> compiled independently from other modules.
Implementation: yes. Header: no.
> Such a construct of course is illegal, because of infinite recursion.
> The same construct would be perfectly accepatble with pointers:
> A = record a1: ^B; end;
> B = record b1: ^A; end;
Yes. But it doesn't even have to so complex. Simply two files having dependancies on
eachother, without having cycles in types are most typical.
> My idea for extended external declarations:
IMHO it is not a problem that needs solving, specially not with extra syntax.
> > IIRC TP could handle mild circular references and so can FPC. I don't know
> > if this is still the case.
> Sounds interesting, do you have more information?
No. It could also be that one of the other devels remember how it exactly went.
I quickly tested, and it doesn't work now:
-bash-2.05b$ fpc unit1
Free Pascal Compiler version 1.9.9 [2005/03/29] for i386
Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: FreeBSD/ELF for i386
unit2.pas(5,11) Fatal: Circular unit reference between unit2 and unit1
Error: /home/marcov/bin/ppc386 returned an error exitcode (normal if you did not specifiy a source file to be compiled)
So if it worked at a certain point it was removed later.
More information about the fpc-devel