[fpc-devel] Unicode and UTF8String

[Martin Friebe]

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
> anyway.
>   
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 
solution.
- a solution with many overloads would defer release
- overloads (currently) lead to code duplication (so that needs to be 
solved first)
- 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)?