[fpc-devel] String and UnicodeString and UTF8String
Hans-Peter Diettrich
DrDiettrich1 at aol.com
Thu Jan 13 03:23:22 CET 2011
Marco van de Voort schrieb:
> 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.
Because it's bound to UTF-16? That's not a problem, because WideString
will continue to exist, and according conversions are still inserted by
the compiler.
>> 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)
When system encoding changes with the target platform, indexed access to
such strings can lead to different results. Unless the compiler can read
the coder's mind...
>> 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?
It's sufficient to throw away what's no more needed :-)
DoDi
More information about the fpc-devel
mailing list