[fpc-devel] Unicode support (yet again)

Hans-Peter Diettrich DrDiettrich1 at aol.com
Fri Sep 16 16:55:18 CEST 2011


Graeme Geldenhuys schrieb:
> On 16/09/2011 11:48, Felipe Monteiro de Carvalho wrote:
>> What about stuff like this in classes:
>>
>>   TReader = class(TFiler)
>>     function ReadString: string;
>>     function ReadWideString: WideString;
>>     function ReadUnicodeString: UnicodeString;
> 
> 
> I'm clearly not understanding your (and a few others) logic here. Why
> must classes like that become obfuscated with such "extra" methods?

I also don't understand that, because external files must have a unique 
format, or they are not exchangeable. Here UTF-8 has the big advantage 
of supporting full Unicode, and the disadvantage that the length of the 
string in a different encoding is not known in advance. I'd leave it to 
the compiler, to insert eventually required conversions, instead of 
bloating the reader and writer classes with extra conversions.

> What is wrong with changing this class definition...
[...]
>    TReader = class(TFiler)
>      function ReadString: UnicodeString;

This IMO should read UTF8String, usable in every environment without 
external (platform, string implementation...) dependencies. Two more 
classes that are not affected in any way by other decisions about string 
types, immediately usable even in a split {$IFDEF Unicode} model.

DoDi




More information about the fpc-devel mailing list