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.

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to