[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();
end;
(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 !)
-Michael
More information about the fpc-devel
mailing list