[fpc-devel] Re: Class field reordering

[Giuliano Colla]

Il 22/07/2012 23:15, Marco van de Voort ha scritto:
> In our previous episode, Florian Kl?mpfl said:
>>> Then "friend" classes as C++ offers and wait for this feature were
>>> implemented before proceeding with the optimization :)
>>>
>> I never saw a C++ class pretending to be somebodies friend. iirc friend
>> classes must be defined in the class which elements shall be access. So
>> C++ like friend classes would help exactly nothing (iirc).
> Indeed, and in our case those friends list would be in precompiled code.
>
> As far as Guiliano's suggestion goes, then I rather use a cmdline option for
> that (when compiled with that option it is allows to access private fields),
> rather than syntax.  (but I don't know if the PPU format actually contains
> enough info to access private fields, so this is probably not easy).
A command line option would make *all* private fields of *all* objects 
fully visible. A different class definition would make visible just a 
few selected classes. It makes quite a difference.
> But since it is apparently not worth discussing individual cases over, IMHO
> that means it is not worth compiler changes either.
There's an issue which isn't individual but general. Free software means 
having the freedom of using it however you see fit for your application. 
This applies to fpc itself, and to fpc based tools, like Lazarus, FPGui, 
MSEide, MSEgui etc. If fpc offered a way to provide a higher degree of 
freedom, it would be a general improvement of fpc. If it were done 
properly it could keep all the advantages of stable guaranteed API's 
with the flexibility required by a large number of individual cases, 
which, taken one by one, would be almost impossible to cope with. Taken 
as a group they make a general case, worth considering.