[fpc-devel] new string - question on usage

Luiz Americo Pereira Camara luizmed at oi.com.br
Tue Oct 11 03:12:53 CEST 2011


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



More information about the fpc-devel mailing list