Personally I'm fine with people refactoring code in order to improve
performance in either the compiler or the programs it compiles, just so
long as it behaves exactly the same as before (which in this case, it
doesn't because of the empty string issue that Jonas mentioned).
Although if I'm not mistaken, I always assume there's going to be a
performance hit if strings are used outside of constants.
Gareth aka. Kit
On 28/04/2019 11:35, Jonas Maebe wrote:
On 28/04/2019 09:55, Ondrej Pokorny wrote:
IMO there is an unnecessary Move() operation in
fpc_AnsiStr_To_AnsiStr if (orgcp=cp).
fpc_AnsiStr_To_AnsiStr creates a copy of the AnsiString even if the
destination and source codepages are equal. See:
program AnsiUtf8;
var
Utf8Str: UTF8String;
RawStr: RawByteString;
Str: string;
begin
DefaultSystemCodePage := CP_UTF8;
Utf8Str := 'hello';
Str := Utf8Str; // this makes a copy (fpc_AnsiStr_To_AnsiStr -> Move)
RawStr := 'hello';
SetCodePage(RawStr, CP_UTF8, False);
Str := RawStr; // this doesn't make a copy
end.
Is there a reason for this?
It's probably what Delphi does as well. The result is that the
refcount of a string after such an assignment is currently always one.
I've had my share for now fighting with people who rely on
implementation details (like this is one), so I'd rather not change
that unless Delphi does it too (and even then we may get complaints
that FPC is not backwards compatible in this respect).
See the attached patch.
Your patch will return an empty string if orgcp is different from both
cp and CP_NONE.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
