[fpc-devel] Unicode RTL

[Daniël Mantione]

Op Thu, 17 Nov 2005, schreef Felipe Monteiro de Carvalho:

> On 11/17/05, Daniël Mantione <daniel.mantione at freepascal.org> wrote:
> > IMHO the "hope" is that if there is a Tnativestring, people will
> > start to design their libraries using Tnativestring, which will result in
> > that those libraries can be compiled for 8 of 16 bit strings.
> 
> This does not fix everything. Some RTL functions would still have to
> be modified even with this Tnativestring.

The RTL needs modifications in any solution.

> I think this can lead to slower compiles and overhead on the RTL.

There would be consequences, even big ones, but not these.

You won't get slower compilations; it doesn't matter much if the 
compiler has to consider a type Tnativestring or ansistring. Overhead is 
zero for non-Unicode rtl. Overhead would be huge when interfacing with non 
UCS-2 stuff.

The widestring is slower than ansistring, but handling utf-8 inside 
ansistring can turn O(N) into O(N^2), which has terrible effects on 
performance.

No, I think implementation of this could put a big wall between Pascal and 
external libraries. That is going to hurt the most. Inside Pascal it could 
be a very comfortable solution.

Libraries important, very important. It might result in more Pascal 
libraries, but also makes using foreign libraries more difficult. For the 
Unicode RTL only, then, but I don't get comfortable with the idea that 
libraries get hard to use.

Daniël