[fpc-devel] Unicode and UTF8String

Martin Friebe fpc at mfriebe.de
Mon Dec 1 22:33:32 CET 2008


Luiz Americo Pereira Camara wrote:
> Martin Friebe escreveu:
>> All the code
>>  Widestring := RtlFunction;
>>  Utf8string := RtlFunction;
>> will run, it may just perform badly.
>
> Yes and no.
>
> Let's assume the platforms windows and unix having UnicodeString 
> (UTF-16) and UTF8String as native types respectively.
> You choose to use UnicodeString type in your app.
>
> Using the rtlstring approach you get:
>
> Under windows: the native string type of platform is the same as you 
> are using no conversion is taken. Good.
> Under unix: the native string type of platform is NOT the same as you 
> are using ONE conversion is taken. Bad.
>
> Now let's assume that fpc team decided to use a fixed unicode encoding 
> for the RTL. Let's say a UnicodeString RTL.
> You choose to use UnicodeString type in your app.
I never suggested the RTL to be in a fixed encoding. I fully agree that 
this would be far worse.

I suggested to have a rtl, that has overloaded functions for each string 
type.
of course that sounds easier than in fact it will be.

Florian pointed out a few issues, like overloading by result is not 
possible (yet?). And code duplication would be a maintenance hell.
But those limits can be overcome. Maybe not in full for the first 
Unicode fpc release.

I can see that in order to get at least something (and in a way forward 
compatible) to all the waiting users of fpc, the RTLString solution is a 
good solution (or compromise: full function, limited optimization).

The functions that can be overloaded with what fpc already has, could be 
written for the various types. Maybe a template system for plain 
functions (like generics for objects) could be found? So code would not 
be duplicated.
Maybe fpc could be extended to allow overloading by result? (sure that 
has other uses too?)
It's just a suggestion.

Best Regards
Martin



More information about the fpc-devel mailing list