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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
