[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?


More information about the fpc-devel mailing list