[fpc-devel] Performance of string handling in trunk

[Marco van de Voort]

In our previous episode, Michael Schnell said:
> > "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.

That already has been decided, everything Delphi compatible. 

I was just speaking hypothetic case.

> 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.

In general, it has been proven time and time again that deviating from
Delphi is nearly always the worse choice.  It just creates two cases to
check for code that must still compile under Delphi instead of just one.

So even if the extra "case" is better, it still produces more heartbreak for
many people. Unless delphi changes it in some later version (since then,
Delphi codebases will be adapted anyway)
 
> 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.

I don't think quirks mode would be useful. It is not just syntax, the
resulting encoding in the string type is different between quirks and
non-quirks mode.  IOW passing strings between an quirks and non-quirks unit
would get very intransparent.

> > 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.

In general the average code doesn't really honour such fine differences, so
in practice this doesn't matter.