Am 28.02.2014 15:01, schrieb Michael Schnell:
On 02/28/2014 01:04 PM, Marco van de Voort wrote:
Moreover, will operations that use character access make sense at all
if you don't know what the actual encoding is?
The administrative record of each "New Delphi string" contains the
encoding type and the byte-count for each code. So "you" (the compiler
and the RTL) do know it.
The "only" shortcoming in Delphi is that the handling is completely
"static":
- if the encoding definition of the type the string is created with
is not "RAW", the encoding needs to be known at compile time (i.e. the
encoding type is not allowed to be modified at run time)
It is possible as some mails a few months back have shown. If you have a
function that has a RawByteString return type then you can assign that
to a string of any static encoding even if the dynamic encoding is not
the same (and then static and dynamic encoding of the string variable
will not match, nevertheless the RTL and the compiler will handle them
correctly (at least I hope so ^^).
- if the encoding definition of the type the string is created with
is "RAW", auto-conversion from this string to a non-RAW is not done.
Hence (including - but not only - for decent use on multiple OSes) an
additional "fully dynamically encoded" type (I suggest to call the
type of this Strings "Generic") is necessary.
The non-conversion nature of RawByteString has its use. Namely to
implement the conversion mechanism of any dynamically encoded type (like
the current AnsiString is) without the need to implement yet another
special construct.
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
