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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
