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.
==============
The guys, this point is important !
All the discussion members are right in their arguments (Martin's &
the "community" impatience to fixing bugs etc because of intensive
using all range of MSEgui facilities- and the need of the FPC team to
keep the proper class hierachy ) & and neither You nor Martin have
enough time to chase tons of code to justify every smallest piece JUST
NOW with hot heads.
So, is it possible to design the new feature in such way that to have
an option to proceed using cracker classes ?
2012/7/19, Jonas Maebe <jonas.ma...@elis.ugent.be>:
>
> On 19 Jul 2012, at 12:21, _-jan...@web.de wrote:
>
>> Unfortunately PACKED is not allowed on all suitable places; there should
>> be packed set
>
> There's the {$packset xxx} directive you can use.
>
>> /array/record/
>
> "packed array" and "packed record" both exist.
>
>> object/class.
>
> Both respect the current {$packrecords xxx} setting ("class" only since FPC
> 2.6.0). If you use {$packrecords 1}, there will be no gaps between the class
> fields and hence nothing will ever be reordered either.
>
>
> Jonas_______________________________________________
> fpc-devel maillist - fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
