In our previous episode, Hans-Peter Diettrich said: > > memory management and the occasional code page conversion (and since > > this may reduce the number of code page conversions when working with > > "non-native" strings, it can also be a performance win). > > IMO a single encoding, i.e. UTF-8, can cover all cases.
Well, for starters, it doesn't cover the existing Delphi/unicode codebase. > While some hard core Ansi coders may whine about such a convention, the > absence of implicit string conversions (except in external library calls) > will make such applications more performant than mixed-encoding versions. I don't see why this is the case. A current system encoding application does not do any conversion. (except for GUI output, and that can be considered negiable to the actual GUI overhead) > Why spend time in the design of multiple RTL/LCL versions, when > a single version will be perfectly sufficient? Why spent 13 years being compatible when you can throw it away in a second? _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
