[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