[fpc-devel] Performance of string handling in trunk

[Hans-Peter Diettrich]

Sven Barth schrieb:
> Am 26.06.2013 14:02, schrieb Michael Schnell:
>> On 06/26/2013 01:40 PM, Sven Barth wrote:
>>> It's the whole use of RawByteString that the encoding is kept. For 
>>> all other string types the content will be converted
>>
>> That is what I did assume, but I understood dodi in a way that he 
>> suggested that it (with normal means such as assigning to another 
>> String) is not possible to make use of the encoding type of a String 
>> information that had been assigned to a RawByteString.
> *sigh*
   +1 ;-)

> See here: http://docwiki.embarcadero.com/VCL/XE/de/System.StringCodePage

The documentation is not complete. Empty strings have no associated 
string record, thus no encoding; StringCodePage always returns the 
CP_ACP for empty strings.

This means that Delphi offers no means to determine the static 
(declared) type of an AnsiString variable (except by RTTI?).

This also requires compiler magic on string assignments, so that the 
static encoding of the target variable can be determined and used to 
force a conversion if required, even if the target is an empty string. 
This magic seems to be buggy, or inconsistent at least, as observed in 
my test programs. When a RawByteString is assigned to an AnsiString 
variable, both variables refer to the same string memory. Afterwards the 
AnsiString can show strange behaviour, as long as it retains a "foreign" 
encoding :-(

 From ms-help://embarcadero.rs_xe/rad/String_Types.html
 >>
The RawByteString type is type AnsiString($FFFF). RawByteString enables 
the passing of string data of any code page without doing any code page 
conversions. RawByteString should only be used as a const or value type 
parameter or a return type from a function. It should never be passed by 
reference (passed by var), and should never be instantiated as a variable.
<<

I'd extend this warning, that a RawByteString never should be assigned 
to an AnsiString variable, because the behaviour of that variable 
becomes almost unpredictable then.
[Unless some newer Delphi version fixes this flaw]


WRT performance, FPC can make use of that undefined behaviour, and 
create the most performant code by not checking and handling 
beforementioned situations. Or FPC can implement more consistent 
behaviour (to be defined).

DoDi