[fpc-devel] Performance of string handling in trunk

[Michael Schnell]

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