On 14 Jul 2012, at 20:52, Jonas Maebe wrote: > On 14 Jul 2012, at 18:02, Martin Schreiber wrote: > >> I do not necessarily want to use field order optimization but if the FPC RTL >> is compiled with it I need to compile my cracker classes with optimization >> too. > > That's indeed true.
That may actually lead to quite some troubles: if someone recompiles the RTL without optimizations, then your class crackers also have to change that setting. And there's no way to detect how the RTL (or in general: units containing classes you are "cracking") has been compiled in your source code. Adding support for something like that is definitely not a road I want to go down -- even a switch to simply treat all "private" fields as "protected" would be less bad (not that I would consider such a switch desirable in any way; it's like adding a switch to allow calling functions only declared in the implementation of another unit). On the other hand, regardless of whether or not we would make that transformation the default for the release units, you will always get problems if someone recompiles the FPC units using the opposite setting. So that's mainly an argument against including this feature altogether in the compiler, at least without additional hacks to make "class crackers" a sort of supported feature one way or another (which I would be quite reluctant to do). This demonstrates a real pain of low level languages: there's almost always at least one way in which someone has figured out a way to break the language, killing a lot of possible optimizations and error checking you would normally be able to do without any problem, unless you want to go through the trouble of annoying at least some users (or, in cases like this one, adding extra complexity to turn that breakage into a supported feature). I once had a discussion with a person who worked on IBM's C compiler, and he said they couldn't even reorder local variables that do not fit in a register because certain large commercial code bases they had to be able to compile "correctly" explicitly relied on buffer overflows from one local variable into the next according to the source declaration order (and annoying those users was not an option). I guess there are probably no such FPC-compiled programs yet (*), so maybe now is the time to add that before we also get stuck with that particular piece of ballast. Jonas (*) except for a few in the FPC testsuite whose purpose is to verify that certain code in fact does not cause a buffer overflow; but those can be easily changed to use all variables of the same size to prevent reordering_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
