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