Re: [fpc-pascal] overloading function StrPLCopy

[LacaK]

When I change definition of 3rd parameter in unicode version of 
StrPLCopy from SizeInt to SizeUInt, then in my example program is 
correctly called "ansi version"
So it seems, that this 3rd parameter confused compiler and somehow 
forced him to prefer wrong version...?

-Laco.


Hi again,
I reply also to fpc-devel list (excuse me, if it is off-topic), 
because I would like understand wat is going on.

I attach also simple test program.
I use FPC 2.6.4 but I think, that same happens also with fresh 2.7.1
Thanks
-Laco.


On 02.05.2014 07:45, LacaK wrote:

Hi,
I am trying understand how FPC determines which version of overloaded
function to call.
Take as example these 2 functions (from SysUtils):
1. function StrPLCopy(Dest: PChar; Source: string; MaxLen: SizeUInt):
PChar; overload;
2. function StrPLCopy(Dest: PWideChar; const Source: UnicodeString;
MaxLen: SizeInt): PWideChar; overload;

And in program I use:
var p: pointer;
  s: string;
begin
   StrPLCopy(p, s, 10);
end;

It seems, that 2nd "unicode" version of StrPLCopy is called. But why?
I am thinking as:
1st parameter is untyped pointer, so no one of function can be prefered
2nd parameter is "string" which exactly match 1st function signature
3rd parameter is "integer constant" which mach both signatures

So it seems to me, that 1st version of function signature matches
better, because of exact match of 2nd parameter ... why is then called
2nd version?


I don't have a explanation for now, but it *might* be important to 
note whether you are using 2.6.x or 2.7.1.


Regards,
Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] overloading function StrPLCopy

[Bruno Krayenbuhl]

You have troubled me seriously, so I have dug in the compiler source.



It appears that when parsing the source, Currency constants are cast to type 
BestReal (EXTENDED on I386) before being converted to the 8 byte currency 
written to the PPU or EXE or whatever is done. The combination of these 
steps DO USE FPU instructions on the I386, the compiler does not use 
SysUtils.StrToCurr to create the 8 bytes currency.




As a bean counter, the point that was really scaring me was whether 
additions and subtractions of Currency's with Currency's would use the FPU. 
It appears that the generated (ASM) code actually uses Int64 arithmetic's 
for these 2 operations. Ouf...




I run FPC 2.6.4 on WinXP machine with an Intel Core 2 CPU 6400 @2.13 GHz s



Here after a program that should test if the compiler is run on a 
problematic CPU




==

program test_Currency_loop;
var
 c:currency;
 cAsInt:Int64;
 // cAsInt64:Int64 absolute c;
 ix:integer;
begin
 c:=92233720368547;
 cAsInt:=92233720368547;
 if Pint64(@c)^<>cAsInt then
   WriteLn('Problematic CPU for Compiler'); // FPU error on machine running 
the compiler Dbg stop point

 writeln(c);
 for ix:=1 to 9 do begin
   c:=c+0.0001;
   writeln(c);
end;
 readln;
end.
==



To test :

1-Compile and run on your XP machine. Copy the .EXE to your W98 machine and 
run it. See the results.


2-Compile and run on your Win98 machine. Copy the W98 .EXE to your XP 
machine and run it. See the results.




I pop my stack and go back to what I was working on.



Regards, Bruno

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal