[fpc-devel] Performance of string handling in trunk

[Michael Schnell]

On 06/26/2013 05:09 PM, Marco van de Voort wrote:
> "Should" is a complex thing here, since there is no implementation to 
> test with (and see if it has other consequences). I assume a 
> conversion should be inserted, so at least for non rawbytestrings the 
> runtime encoding always matches the compiletime one. 
I feel such  implementation details are up to the fpc developers to 
decide. If everybody agrees that doing a conversion when a RawByteString 
is assigned to a normal String and the dynamic encoding does not match, 
is the better alternative vs the potentially unpredictable behavior in 
DXE??, I think this should be the default behavior in fpc.

It might be nice to add Delphi quirks modes that issue an error message 
in that case or just do the assignment even if an "intersexual" String 
(the static encoding that the compiler sees does not match the dynamic 
encoding) is the result with unpredictable consequences.


>> The result could be a strange thing that is encoded
>> other than the type requires. To me this behavior is a quirk go and
>> should not be capt just for compatibility. .
> The whole concept is about compatibility, and that is a race that has
> already been run.
The "incompatibility" only arises when doing something that in Delphi XE 
is depreciated according to the docs (assigning a RawByteString to a 
normal String), anyway. Thus I don't see any problem with implemented a 
sensible behavior in that case.

Another option would be to invent yet another String type that basically 
is a RawByteString but at compile time is used differently just in that 
when assigning it to a normal string that does not match the dynamic 
encoding, the conversion library call is done. (In fact this always was 
my initial idea, in fact: giving the name RawByteString back the 
meaning, the name suggests.) When doing so assigning a RawByteStrinig to 
a normal String could be strictly forbidden (unless some Delphi Quirks 
Mode is set). But I do see that the additional complexity of defining 
jet another String type might be not nice.

-Michael