[fpc-devel] new string - question on usage

[Hans-Peter Diettrich]

Michael Schnell schrieb:
> On 10/11/2011 11:20 AM, Hans-Peter Diettrich wrote:
>> Michael Schnell schrieb:
>>> Why should a function Utf8ToLower be used (or even be  defined for 
>>> normal use) ?
>>
>> Because it expects and UTF8 argument, and provides an UTF8 result, so 
>> that no further conversions are required when used with strings of 
>> exactly that encoding.
> I don't understand your argument. If ToLower gets a new string that is 
> UTF8 encoded, the result should be a new string that is UTF8 encoded. So 
> why bother. Checking the encoding Word and branching tho the appropriate 
> encoding-aware functionality is a very fast operation.

Why implement the upper/lower translation N times, when afterwards the N 
encodings have to be converted into the Result encoding? Where the 
encoding conversions already exist...


>>> With dynamically encoded Strings "ToLower" should work for any encoding.
>>
>> You mean something like this?
>>   function ToLower(s: RawByteString): RawByteString;
>> [dunno whether RawByteString is an allowed Result type at all]
> In fact I still don't understand the difference between a type called 
> "RawByteString"and a basic new String that happens to be set to the 
> encoding "RawByte".

I only have the Delphi implementation at hand, and there every string 
type has an associated encoding. E.g. the default AnsiString has 
codepage 1252 encoding, and when a string is assigned to such a 
variable, it is converted into codepage 1252. The *only* exception is 
the RawByteString type, which can have any encoding.


> IMO, calling ToLower with a string that is set to the encoding "RawByte" 
> does not make sense and should generate an exception.

When a string is assigned to an RawByteString, both point to the 
original string, which has a valid (non-raw) encoding. The only 
exception is an empty string, with a Nil pointer and consequently no 
stored encoding - but such a string never deserves any conversion.

DoDi