[fpc-devel] Performance of string handling in trunk

Hans-Peter Diettrich DrDiettrich1 at aol.com
Tue Jun 25 13:19:33 CEST 2013


Michael Schnell schrieb:
> On 06/25/2013 01:05 AM, Hans-Peter Diettrich wrote:
>>
>>
>> A RawByteString can obtain any encoding, so no conversions are required.
>> But when assigned back to an UnicodeString, the obtained encoding is 
>> used to convert the string.
>>
> That sounds good. The name "RAW" just misled me to think it would not 
> hold a character encoding.
> 
> If this in fact is a completely dynamically  encoded string type, things 
> like TStringList should use same in their interface, thus preventing all 
> conversions, when a string of any encoding type is stored there and 
> retrieved to a variable of the appropriate dedicated encoding type 
> (while being auto-converted if retrieved to variable forcing a different 
> encoding).

This is not the case :-(

A variable can not force a conversion, when a RawByteString is assigned 
to it :-(

> Only the documentation 
> http://docwiki.embarcadero.com/Libraries/XE4/en/System.RawByteString 
> shows that they seemingly are not convinced that all this decently works 
> :-( .

At least it doesn't work as you expected.

> So a decent system should _additionally_ provide completely unencoded 8, 
> 16, 32 and 64 Bit entity Strings for "technical" usage (similar to pipes 
> etc) (now not using the "RAW" naming :-) .

It's *only* the use of strings of different encodings, that make 
conversions necessary. Efficient code must be based on a single 
encoding, with conversions only from and to the outer world (OS, files...).

DoDi




More information about the fpc-devel mailing list