[fpc-devel] Unicodestring branch, please test and help fixing

[JoshyFun]

Hello Graeme,

Wednesday, September 10, 2008, 12:36:17 PM, you wrote:

GG> Remember, Unicode support is much more that simply storing and
GG> displaying text. You have various encodings, RTL or LTR direction etc.
GG>  I can't see how a simple type can keep track of all such information
GG> - but then, I don't know the internals of FPC either.  ;-)

Yes, but most proposals here about a TCharacter are a bit overkill. In
example languare reference for a given char is not very important from
a Unicode point of view, unicode focuses its power in the text, so
locale is important in context operations and collations.

From my point of view the compiler basic types must keep being
"basic", so be fast, no more than needed memory eaters and so on.

Bring Unicode "power" to the basic string type is overkill, any
Unicode operation will be in the better case double time consumer, and
some of them 40-50 times slower. A simple collation will take at least
4 times the memory needed by the string itself and for most sort
algorithms needs the collation is unnecesary. So think in a "new" user
filling a TStringList with 1000 strings and invoking the Sort method,
as the strings are Unicode they must be ordered using the locale
collation or the general collation and finally saying "20 seconds to
sort 1000 strings!!!!, this looks even worst than javascript!!!!".

Maybe, again from my point of view, it is more logical to create
"TTextUnicodeChar" and "TTextUnicodeString" classes which handle
Unicode textual data, not Unicode data.

PS: As one of the problems of Unicode support is the big amount of
data that must be stored (in exe or external file) is there any
recommended way to code, that unused arrays are left out when the
function that uses that array is never been called in the main program
?

-- 
Best regards,
 JoshyFun