On 10/10/2011 19:18, Jonas Maebe wrote:
On 11 Oct 2011, at 00:06, Luiz Americo Pereira Camara wrote:
What about the Marco proposition of having separated versions of RTL/Classes
for UTF8 / UTF16? Or did i miss something?
That would not change the meaning of the "string" type. The code in rtl/classes
would then use a custom string type (RTLString or whatever) that is defined as either an
utf8string or a unicodestring based on some define.
A snippet from Marco earlier mail in this list
"
The constant pressure from the Lazaurs team was the main rationale to come
up with two RTLs. Since the original unicode discussion on core (early 2009,
just before 2009 came out) came up with a type that was mostly UTF16 on
Windows.
People always whined about overloading as a solution, but that won't work
because of virtual methods with string parmaeters or returnvalues in it.
Moreover even if Lazarus decided to migrate to that, it would be totally
broken for a long while till it caught up. The current route is friendlier.
In the UTF8 RTL, all "string"s_ARE_ utf8, unless specified otherwise (by
naming them unicodestring or ansistring(..encoding) or shortstrings).
So the same virtual method with a STRING parameter will be TUnicodestring
in the UTF16 rtl and UTF8string in the utf8 RTL.
"
Luiz
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
