[fpc-devel] Unicode RTL
daniel.mantione at freepascal.org
Thu Nov 17 15:20:52 CET 2005
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
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
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.
More information about the fpc-devel