[fpc-pascal] Unicode file routines proposal

[Felipe Monteiro de Carvalho]

On Mon, Jun 30, 2008 at 11:35 AM, Marco van de Voort <marcov at stack.nl> wrote:
> I understand the simplicity of one encoding is appealing, but you have to
> look at all aspects, and that is not just representation in the GUI.
>
> It will mean that _every_ string transactie to the outside will have to be
> manually wrapped AND have a performance penalty. That is a heavy price to
> pay for not touching a bit of lfm loading code.

It won't need to be wrapped in platforms which nativelly support the
choosen encoding. UTF-16 is natively supported in Windows and Windows
CE. Not sure on unixes.

Because LCL uses a single encoding this performance difference
disappears as soon as you need to convert the string in LCL.

> How many systems do you know have datafiles of like .lfm's over system
> borders?

Gtk can load XML files, somewhat equivalent to our LFMs. They use
UTF-8 everywhere.

Java is cross-platform and uses UTF-16 everywhere.

wxWidgets uses UTF-16 everywhere.

Let me try to sumarize my oppinion on multiple encodings vs single encoding:

multiple encodings:

* More complex
* Innovative solution, no known example of a implementation of this
system exists = uncertainty if it works at all, or if it is convenient
for developers
* Depends on a not yet implemented string type
* Potentially will have a higher performance then a single encoding
system, but only if you use this new special string type

Single encoding:

* Simple, proved solution
* Does not need any new string type, can start being implemented immediately
* Potentially has a lower performance due to string conversions.

Actually for Lazarus the only advantage I see in the multiple encoding
system does not exist, because we use a single encoding system in some
platforms we will need conversion and in others we won't need, which
just makes things worse for us.

-- 
Felipe Monteiro de Carvalho