overloading issues fpc3.2.2

[jamie]

It appears the compiler cannot pick correctly between a Tcolor and an Integer.

if the integer overload is first in order, that gets picked instead of the Tcolor.
 The same is true if TColor is first in order and an Integer gets picked, Tcolor overload will get called instead?

 I know a Tcolor results to a integer in definition in the graphics unit but this can not happen because they are treated differently in my code.

For the time being, I replaced the TColor with a TColorRec which is a Record and that resolved that, but this caused a complete global fix of the sources.
 This isn't the only example. It seems related types get selected instead if they come first in the order listing in the sources,
 Have latter versions of FPC corrected this?

[LeP]

In Delphi it was not compiled, until you don't cast the value ...

[Martin_fr]

I am not sure if it addresses this issue. But from memory, I think that the declaration of TColor was changed (and due to either that or something similar).

But I am to busy to test it now.

[marcov]

I am not sure if it addresses this issue. But from memory, I think that the declaration of TColor was changed (and due to either that or something similar).

But I am to busy to test it now.

Moved to uitypes.  Maybe it was "Tcolor = type integer;" in the past, but that never solved much either.

[cdbc]

Hi
I've gotten away with

Code: Pascal  [Select][+][-]

1. /// TColor = type cardinal;
2. Panel1.Font.Color:= cardinal($FFEE0064); /// BGRA ~ clAqua-Alpha=100

Regards Benny

[Thaddy]

It is a bit more complex than that.
type TColor = -2147483648..2147483647;

As far as I know Lazarus follows Delphi quite close, so https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.Graphics.TColor

Mind the highest order byte explained there.

Also mind that in the 16 bit era the definition was even worse than that.

[dsiders]

system.uitype in RTL defines TColor as LongInt.

Lazarus now defines TColor as TGraphicsColor where:

{$ifdef UseSys]"]>BlockedITypes}System.UITypes.TColor{$else}-$7FFFFFFF-1..$7FFFFFFF{$endif};

All of this took place when TColor was appropriated by RTL... probably for Fresnel.

[EDIT]

ifdef trashed by forum code formatter...

[Martin_fr]

The word System_UItypes contains a well known "sell very cheap marketplace" for which the forum receives spam. So the name of that is black listed. Unfortunately the blacklist does not check word bounds.

I fixed your message.

I tried to enforce the forum to check for spaces, but I don't know if that will work for long, or if I need to search a diff solution.

[jamie]

This is getting frustrating since now I have determined that the compiler can't tell the difference an Integer and a record of the same size.

The compiler seems to understand the primitive types, but when it comes to records it picks a primitive of the same size.

for example, a TcolorRec that has R,G,B,A:Byte in it, translate to an integer so if there is an overload longint for example, the compiler picks that one instead, because it's the same size.

 The strange thing is that I found this when a TColorRec overload was calling the LongInt over instead. The two are handled much differently.
 
  So, I did a build all and after that, the compiler keeps stopping at the line I specify a TColorRec and states it is looking for an LongInt and refuses to pick the TcolorRec overload.

 Apparently from what I can see, the compiler simply dispatches a primitive type matching the same size of the record.

 So, I have like 6 overloads, all the same structure but different types. One of them do work and is a record but that is only because the size of the record is 8 bytes and I don't have a Uint64 in the list but If I do have it in the list, that too gets used over the correct entry containing the 8 byte record, because they are the same size.

 This is bizarre to the same the least, even CODE tools can't pick the correct one.

Is there any form of TYPEINFO I can use to force the compiler to pick the RECORD type over the matching primitive types?

I was thinking of Trying to use a Generic to generate all these overloads, but I think that too may fail.

Jamie from my laptop.

[LeP]

Apparently from what I can see, the compiler simply dispatches a primitive type matching the same size of the record.

It's difficult to believe into this. That should means that the compiler could make wrong things with many and many projects.

Can you post a very simple source, so we can try ?

[marcov]

system.uitype in RTL defines TColor as LongInt.

Lazarus now defines TColor as TGraphicsColor where:

{$ifdef UseSys]"]>BlockedITypes}System.UITypes.TColor{$else}-$7FFFFFFF-1..$7FFFFFFF{$endif};

All of this took place when TColor was appropriated by RTL... probably for Fresnel.

No, since I did that, and I have never even seen Fresnel.  It was needed for color use in fcl-image and web related stuff, not necessarily also a whole alternative GUI option. And compatibility of course.

Same for the table with so called "webcolors" that also moved to system.uitypes.   FPC 3.2.4 will take the next step in moving simple enumerations to system.uitypes in a Delphi compatible manner.

[jamie]

I fixed it using generic functions instead of hard coding the overloads
The compiler is now pointing to the correct calls.

This problem only seems be in remote units and the app is getting large to say the least.
when i test with a small app it always works.

I don't use the Tcolor anymore, I have a TColorRec and that was working until the app starting getting a little larger then the
compiler started doing this.

 Not sure if I switch back to TColor using generics if this would work?

 in a slightly off topic state
  I switched to the 32 bit Lazarus/Compiler and I noticed the compiler and environment seems to be faster than the 64-bit tool set and compiler, has anyone noticed this?

 This app must be able to run on both targets, 32 for the smaller end task the app offers and 64 for larger projects only for memory needs for larger projects.

 This is a combination Electronic Design cad, Ladder cad, wire bundle calculates for tray/race ways cabinet and panel layouts

Jamie

[Thaddy]

The 32 bit intel/amd compiler generates in some circumstances faster code indeed. That is true. If you should bother?

[LeP]

Regarding this topic, I think there's something wrong with Lazarus/FPC...
The definition of TColor is identical in both Delphi and Lazarus.
The exact same code in Delphi (I mean real Delphi) generates different results, and in Delphi the result is the expected one.

Look at two images, report here also the code (the same in Lazarus and Delphi):

Code: Pascal  [Select][+][-]

1. const
2.   clmyRed: TColor = 255;
3.  
4. procedure A1(p: TColor); overload;
5. procedure A1(p: Integer); overload;
6.  
7. var
8.   Form1: TForm1;
9.  
10. implementation
11.  
12. {$R *.lfm}
13.  
14. { TForm1 }
15.  
16. procedure A1(p: TColor);
17. begin
18.   writeln('Color');
19. end;
20.  
21. procedure A1(p: Integer); overload;
22. begin
23.   writeln('Integer');
24. end;
25.  
26. procedure TForm1.Button1Click(Sender: TObject);
27. var myint: integer;
28. begin
29.   myint := clmyRed;
30.   A1(clmyRed);
31.   A1(myint);
32. end;

PS: Lazarus 4.6 / FPC 3.2.2 stable

[LeP]

I don't use the Tcolor anymore, I have a TColorRec and that was working until the app starting getting a little larger then the
compiler started doing this.

BTW, Delphi has TColorRec definitions too. And this is the new definitions used by colors (as clRed, clYellow, etc ...). This is generically compatible with the old code, but in the case of my last example the use of new standard color def. doesn't work at all, because it is seen by the compiler as an integer.