[fpc-devel] Is calling the Windows Unicode APIs really faster than the ANSI API's?

[Daniël Mantione]

Op Fri, 26 Sep 2008, schreef Marco van de Voort:

> In our previous episode, Dani?l Mantione said:
>>> That's highly dependant on what you application does!  If your
>>> application primarily parses text files, it's relevant. :-)
>>
>> Shortstrings & ansistrings won't go away. You'll still be able to code
>> fast text file parsers. Note that in such cases your application won't
>> process unicode, taking the numbers example again: As soon as your
>> application accepts arabic numbers everywhere western numbers are allowed,
>> you want the parsing to happen in UTF-16.
>
> Accepting both Arabic and Westernized Arabic numerals would possibly break a
> lot of code anyway, since to string and back wouldn't be reversible.

It has never been reversible. Think about val('$100',v);

> actually already isn't with Delphi I know, due to hex and padding handling,
> but this would be a magnitude worse)

You want to handle it transparently. Otherwise you get a mess like 
that people need all kind of ugly case constructs, having to call a 
different "val" routine depending on the language the program is shown in. 
That way you never will get good multi-lingual support.

For many people Unicode is just "let's go UTF-8". It's far more than that 
and 100% supporting Unicode is even next to impossible.

> You can't seperate val from str, and what would str(100,s) do?

It could accept an extra optional parameter for the desired script or 
something like that.

Daniël