[fpc-devel] Re: Class field reordering

Ivanko B ivankob4mse2 at gmail.com
Sat Jul 21 20:47:40 CEST 2012

I don't see cracker classes as valid code.
Then the FPC team should eliminate the need in such crackers - via
either disabling (via licencing, prisoning etc) the "impatient"
[mainly because of impatient customers] non-mainstreams (non-Lazarus)
or meeting needs of the non-mainstreams ( the above "{$ifdef
nonLazarus}" etc ).

2012/7/21, Florian Klämpfl <florian at freepascal.org>:
> Am 21.07.2012 18:48, schrieb Martin:
>> On 21/07/2012 16:55, Ivanko B wrote:
>>> The problem now is that cracker classes can't be used in future anymore
>>>   because of the new class field ordering optimisation, so I dared to
>>> ask.
>> ....
>>> So, is it possible to design the new feature in such way that to have
>>> an option to proceed using cracker classes ?
>> But the whole discussion comes down to one other simple question.
>> Including the above, the whole discussion is about:
>>    Should FPC provide a way to access private fields from any other code?
> I don't see cracker classes as valid code. If it works, fine, but it is
> subject to break. The layout of classes is simply opaque else we open a
> whole can of worms: like fixed vmt layout or whatever.
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel

More information about the fpc-devel mailing list