[fpc-devel] Unicode support (again)

Michael Schnell mschnell at lumino.de
Tue Nov 11 13:34:05 CET 2008

> Remember that an individual code point does not nessacerally represent 
> what a user would consider a character. ...
Again, there is no compatible handling of this with good old 
ANSIStrings, anyway, so there is not "friendly old school" way that a 
compiler would be able to offer. In these special cases, the user of 
course needs to explicitly handle the upgrade of his project to unicode. 
If the differences or ambiguities are relevant in the project in 
question, the user of course needs to write code for that. Only if 
handling the issue in the same "old school" way as ANSIStrings provide, 
the user should be able to write the same code as he is used to do.

> Given theese facts code point counts and indexes are not much more 
> usefull than code unit indexes and counts.
I never said that "code point counts and indexes are more useful", but 
forcing the programmer to create much more complex and less straight 
forward code only because the underlying system now uses unicode, even 
if he would be perfectly happy with ANSI, does not make much sense to 
me. If he really needs unicode specifics (or wants to optimize his code 
for space or time) he of course should be aware that things are complex 
and he needs to dig deeper.

Do you really want to explain a newcomer that and why he can't any more do

s: String;

s := edit1.text;
case s[1] of
 'a': do_this();
 'รค': do that();

(with String being ANSIString; UTF8String or WideString.).

Wait a minute:  UTF8Char in case triggers another problem :) :) :) 
...... But at least ANSIString and WideString should work as expected 
(independent of the source code being code as ANSI or UTF8 !)


More information about the fpc-devel mailing list