[fpc-devel] Encoded AnsiString

[Michael Schnell]

On 01/07/2014 03:35 PM, Hans-Peter Diettrich wrote:
>
> What if FPC adds another encoding, similar to RawByteString ($FFFF), 
> but without the Delphi quirks? Or simply fix the RawByteString flaws 
> in the *Ansi* compiler and RTL?
+1 (in fact I elaborated on that in some older Threads here)
>
> 1) In a discussion in the Embarcadero groups it turned out that, in an 
> assignment of a RawByteString to another AnsiString type, the Delphi 
> compiler should (but does not) check and eventually convert the string 
> to the static encoding of the target. This is (almost) the only way to 
> create strings with a different static and dynamic encoding.
+1
>
> 2) The stupid conversion to CP_ACP in an assignment *to* an 
> RawByteString should be dropped. This applies in detail to the 
> assignment to *function results*.
>
> 3) The function result type should be honored, in functions accepting 
> RawByteString parameters. The Delphi compiler seems to *assume* that 
> the results of such functions is RawByteString, so that (including 
> beforementioned flaws) the outcome is a CP_ACP string, even if the 
> declared function result is e.g. an UTF8String.
I offered some similar thoughts about how to define and implement such a 
"fully dynamically encoded" string type and how it can be implemented 
without harming performance, even it TStrings and siblings (and the 
Lazarus API) in fact use it for sake of flexibility and portability.

For Delphi compatibility this needs to be a new encoding type (say 
$FFFE), and provided with some appropriate name.

-Michael