On Thu, Nov 20, 2008 at 1:50 PM, Michael Schnell <[EMAIL PROTECTED]> wrote: > >> Compiler support for a unicode string is not enough for the LCL. >> As long as base classes like TStrings uses ansistrings, the LCL must use a >> string type, that does no conversion. > > Of course you are right that the RTL needs to be made up accordingly. Maybe > TStrings and friends are needed in multiple versions.
Yes, I would have thought that's a given. All base classes need unicode support where appropriate - that includes TStrings. > Using a string type that dynamically can be used top hold multiple encodings > (as discussed here, too) sounds nice, if it does not result in too slow code > (due to the necessity of checking for the coding with any operation). At the moment, I think first supporting Unicode is the most important step. Performance tuning comes afterwards. That how it seems to work now and I don't see a problem with that. FPC generates assembler code, and it's still an ongoing process in tuning the performance of the assembler code. I remember how things where tweaked a while back with all the language shootout tests. We can implement Unicode shootout tests later. ;-) Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
