On 06/25/2013 01:19 PM, Hans-Peter Diettrich wrote:
This is not the case :-(
A variable can not force a conversion, when a RawByteString is
assigned to it :-(
I suppose you decently tested this with the newest version of Delphi XE.
I can't comment, as I dont have DXE. :-( .
But you and the docs state, that RawByteString is not intended to hold a
string of unencoded raw bytes that never are supposed to represent
printable characters, but despite of its name it is (e.g.) supposed to
be used as formal parameter, a String holding printable characters with
a known encoding is to be assigned to. Thus I in fact fail to see the
sense of it existence, if really the information about the encoding type
of the string, assigned (without conversion) to it, is lost.
OTOH it seems to be easily to understand and to implement that/if the
dynamic EncodingTyp tag (that according top the docs exists in the
string management record together with the ContentPointer, the
StringLength and ReferenceCounter) is updated with that information
during the assignment (in the same way as ContentPointer and
StringLength). This would allow for decent use of such a type variant
and IMHO should be the way to go for fpc. This would be perfectly
compatible, even if Delphi does not allow for such usage of the
RawByteString Type. It would not slow down anything if you don't use
that feature, and IMHO the performance hit would be close to zero (and
still rather compatible) if implementing stuff like TStringList using
this feature.
Effect:
- Such a TStringList would be able to work with any String type
without ever forcing an auto-conversion (unless you check out a string
to a variable of a different (static) type).
- Lazarus could use such a string type as it's interface to the user
code. This would allow for using greatly the same code for multiple
archs, independent of the user code. IMHO, the performance hit for this
should be small, as these interface functions mostly are not used in
very long close loops.
-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
