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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
