On 10/10/2011 19:18, Jonas Maebe wrote:
. In a future delphiunicode mode or something like that string will be
unicodestring
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.
So in resume the unicode version of fpc classes unit will have String =
UnicodeString/UTF16 always
Ok. This in practice will force Lazarus to go to UTF16 since renaming all
string types of LCL from String to UTF8String is a no-no, at least for me.
I really don't see how adding a feature to the compiler to change the default
definition of the string type would change anything.
I was assuming that would be a version of UTF8 classes unit where string
= UTF8. So i think that would be possible to choose the UTF8 unicode
classes and force Lazarus to be compiled with String = UTF8 to match
As I said, you can achieve exactly the same result by using a custom defined
string type.
Yes and as i said is a no-no (in my humble opinion) for Lazarus to
change from String to UTF8String or LazString. There are tons of code /
components under Lazarus/LCL ecosystem that would need such change. Also
porting Delphi VCL components would be a lot harder. What about the form
resources streaming? Change string types with search and replace?
But lets say Lazarus wants to stay with UTF8 and choose to go with your
suggestion and change to a custom string type like UTF8String.
Under unix i would have LCL (UTF8) <> Classes (UTF16) <> RTL (UTF8)
It will be impossible to track / avoid string conversions
Luiz
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
