On Thu, 23 Sep 2010 11:10:45 +0200 "Guy Fink" <[email protected]> wrote:
> --- Ursprüngliche Nachricht --- > Von: Felipe Monteiro de Carvalho <[email protected]> > An: [email protected], Lazarus mailing list > <[email protected]> > Betreff: Re: [Lazarus] rewriting of LConvEncoding > > > 2010/9/20 <[email protected]>: > > > I would rewrite the entire unit > > > > Great, just make sure you take all variables into account: > > > > * code size (check if your tables are smartlinkable. The current ones > > are) > > * speed > > * maintenability > > > > On Mon, Sep 20, 2010 at 10:16 PM, Mattias Gaertner > > <[email protected]> wrote: > > > And the tables are quite big. Maybe the unit should be splitted > > into > > > several units. > > > > In my tests the asian tables are smartlinked and won't be added unless > > necessary. > > > > Splitting into several units is also possible, but then a registration > > mechanism should be added. > > > > -- > > Felipe Monteiro de Carvalho > > My first idea of the structure then: > > A ConvertEncoding-unit, containing all the necessary types,constants, > function prototypes and the Unicodestuff. (conversions between the different > UTF-variants). It could hold some jumptables for the conversion procedures, > which are initalized to a local dummy function. > > Then I do not generate include files, but a complete unit for every codepage > we add. This unit will register itself to the ConverEncoding-unit in its > initialisation part. So the user has full control over supported codepages of > his application by simply using the the needed codepage-units. I think one unit per group is sufficient. For finer granularity there is smartlinking. Mattias -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
