[fpc-devel] Class field reordering

Martin Schreiber mse00000 at gmail.com
Wed Jul 18 08:19:02 CEST 2012

On Tuesday 17 July 2012 09:40:36 michael.vancanneyt at wisa.be wrote:
> > Maybe, but what about performance? Another complication is the
> > "updatebuffer" with the "oldvalues".
> Thinking about it:
> I would allocate the buffer as is, with for all string fields an
> integer-sized slot in the buffer. The slot contains an index, pointing
> to a separate array of strings containing  N*M*2 strings. (N=number of
> records, M= Number of string fields per record, factor 2 for old values)
> Field value =  Element [Index  [+1 for old value]] in the array.
> where the [Index] is stored in the buffer.
> The speed performance penalty of this system should be negligable, since
> you assume all records are in memory anyway.
> And: everything can be done without meddling with the internals of TField.
Thank you. There are more items in the db.pas list...
But I think first we should concentrate on classes.pas because I really don't 
want to fork it. Forking db.pas is less problematic and I probably prefer it 
in place of an endless discussion and in my eyes not optimal solutions. With 
a forked db.pas I can eliminate the many workarounds I already had to 

Currently needed crackerclasses by MSEide+MSEgui:

Used by MSEide for different tasks (example: ask for ancestor forms and 
frames/submodules while loading a form/datamodule, recover in case of an 
error) and for streaming of frames with additional components/widgets:

- FComponents
- FComponentState
- FFreeNotifies

- FPropPath
- FAncestors

- FStream
- FLoaded

Used in order TParams create tmseparam items instead of TParam:

- FItemClass

Used to unify memorystreams/files/pipes/sockets/stringstreams:

- FHandle

- FCapacity

Why must these fields be private?

Thanks, Martin

More information about the fpc-devel mailing list