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