On 06/26/2013 02:59 PM, Sven Barth wrote:
It's a counter argument to "it is not possible to make use of the
encoding type of a String information that had been assigned to a
RawByteString". This function returns the current code page of the
string. And using SetCodePage you can force a conversion.
I don't see the problem.
(1)
fpc does not need to closely follow Delphi with stuff that is only
seldom used by average application programmers, if there are decent
reasons to do another (better) decently compatible implementation.
(2)
According to the description, StringCodePage returns "the Codepage".
According to your wording it returns "the current code page". With
normal strings the _current_ (aka dynamic) code page always is identical
to the code page the string had been given (by the compiler) when
instantiated. (Otherwise the string would be "intersexuel" or erroneous
and will behave erratically). That is why the (floppy) wording of the
description omits this difference.
As you stated before, the RawByteString _does_ preserve the encoding
type of the information that is assigned to it. It can only do this
using its dynamic "EncodingType" field. Thus it makes sense that the
function returns the dynamic EncodingType with RawByteStrings.
Thus it simply always might return the dynamic EncodingType.
And this is exactly the information that (IMHO) should be used when
auto-converting, with the only exception when assigning _to_ a
RawByteString (_static_ encoding Type $FFFF). That easily can be decided
by the compiler at compile time (that here and in many other cases does
not even need to call the library, as assigning is simply done by
setting the pointer and increasing the RefCount), which IMHO should be
done "inline".
-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
