On Mon, Jun 30, 2008 at 11:35 AM, Marco van de Voort <[EMAIL PROTECTED]> wrote: > I understand the simplicity of one encoding is appealing, but you have to > look at all aspects, and that is not just representation in the GUI. > > It will mean that _every_ string transactie to the outside will have to be > manually wrapped AND have a performance penalty. That is a heavy price to > pay for not touching a bit of lfm loading code.
It won't need to be wrapped in platforms which nativelly support the choosen encoding. UTF-16 is natively supported in Windows and Windows CE. Not sure on unixes. Because LCL uses a single encoding this performance difference disappears as soon as you need to convert the string in LCL. > How many systems do you know have datafiles of like .lfm's over system > borders? Gtk can load XML files, somewhat equivalent to our LFMs. They use UTF-8 everywhere. Java is cross-platform and uses UTF-16 everywhere. wxWidgets uses UTF-16 everywhere. Let me try to sumarize my oppinion on multiple encodings vs single encoding: multiple encodings: * More complex * Innovative solution, no known example of a implementation of this system exists = uncertainty if it works at all, or if it is convenient for developers * Depends on a not yet implemented string type * Potentially will have a higher performance then a single encoding system, but only if you use this new special string type Single encoding: * Simple, proved solution * Does not need any new string type, can start being implemented immediately * Potentially has a lower performance due to string conversions. Actually for Lazarus the only advantage I see in the multiple encoding system does not exist, because we use a single encoding system in some platforms we will need conversion and in others we won't need, which just makes things worse for us. -- Felipe Monteiro de Carvalho _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
