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

[Marco van de Voort]

In our previous episode, Daniël Mantione said:
> >
> > 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);

See one line further down.
 
> > 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.

IMHO one should separate GUI val from system val. IMHO it is a presentation
layer problem and should be dealt with there.
 
> 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.

Correct, but that is what I'm suggesting. UTF-16 is not a cure all either,
only at a first superficial glance. I'm btw not for UTF-8, but for working
in the native encoding per platform.

> > 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.

If you think that is acceptable, you can also do it for val.