[fpc-devel] Unicode and UTF8String
fpc at mfriebe.de
Mon Dec 1 23:01:23 CET 2008
Marco van de Voort wrote:
> In our previous episode, Mattias Gaertner said:
>>> Florian Klaempfl wrote:
>>> My opinion is that it should be the programmers choice. I a
>>> programmer wants or needs a simpler way (keeping all the strings in
>>> is application in one format, which will be known to him) then he/she
>>> should have that choice. And then on this type the person could
>>> perform any index or index-like operation.
>> About: keeping all the strings in is application in one format, which will be known to him
> This is not possible, since you don't control OS + headers. Most stuff will
> come from the outside in the system encoding.
> This way you can do the whole app in the system encoding, and only face
> conversions when outputing to the GUI, which is (relatively) infinitely slow
I never needed an argument for the introduction of RTLString. It's a
great idea. It allows a programmer at hi/her choice to make applications
much more portable.
Even so, in fact it is not new. You could always just have introduced
your own type, and set it OS depended with a few IFDEFs
I argue against a RTL that *only* provides a RTLString interface.
Instead of various overloaded methods (see other mails, for which set of
functions/methods this actually makes sense).
I have however so far got good arguments for starting with RTLString
- a solution with many overloads would defer release
- overloads (currently) lead to code duplication (so that needs to be
- overloads are not possible based on function results
But on the long term (fpc 2.6 or maybe 2.8) surely those issues can be
overcome (if wanted)?
More information about the fpc-devel