[fpc-devel] String and UnicodeString and UTF8String
Hans-Peter Diettrich
DrDiettrich1 at aol.com
Tue Jan 11 17:19:42 CET 2011
Jonas Maebe schrieb:
> This has the advantage that you always have all optimal implementations
> available, regardless of the platform or default string encoding. It
> does not require extra work because we have to write all those versions
> also if we want the RTL to be compilable for different default string
> encodings. And three checks in a case statement are not going to define
> the performance in a context of atomic reference counting, dynamic
> 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. 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.
The argument "my characters *always* will be inside my preferred
codepage" will prove false sooner or later. While it's not up to a
programming language to teach people the "better way of coding", the
required efforts of the FPC/Lazarus developers IMO should have more
weight. Why spend time in the design of multiple RTL/LCL versions, when
a single version will be perfectly sufficient?
DoDi
More information about the fpc-devel
mailing list