[fpc-devel] "Friend" classes?

[Marco van de Voort]

> 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
> changes?

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.

[snip]
> Such a construct of course is illegal, because of infinite recursion.
> The same construct would be perfectly accepatble with pointers:
> 
> type
>   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
Compiling unit1.pas
Compiling unit2.pas
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.