Questo è un bug ?

[DragoRosso]

Ciao, vi propongo questo codice ripreso dal forum internazionale (https://forum.lazarus.freepascal.org/index.php/topic,73909.msg581815/topicseen.html):

Codice: [Seleziona]

program Project1;

uses SysUtils;

type
  TColor = -$7FFFFFFF-1..$7FFFFFFF;

const
  clmyRed: TColor = 255;

procedure A1(p: TColor); overload;
begin
  writeln('Color');
end;

procedure A1(p: Integer); overload;
begin
  writeln('Integer');
end;

var myint: integer;
begin
  myint := 87;
  A1(clmyRed);
  A1(myint);  //QUESTO dovrebbe chiamare la versione "Integer" non quella "Color" ...
  ReadLn;
end.

Provate a farlo girare, e vedrete che stamperà due volte "Color" a terminale. Eppure il codice è chiaro ...
Il perchè viene fatto ciò rimane oscuro, però è preoccupante se non si riesce a dare una spiegazione credibile.

E' certo che il valore 87 è all'interno del range di TColor, e quindi potrebbe essere confuso ... ma il tipo che lo contiene è integer ed è un tipo diverso da TColor.

Ma anche se fosse, se le due definizioni delle procedure in overload non sono distinguibili, il compilatore DEVE generare un errore.
Da notare che Delphi genera la corretta sequenza Color / Integer sul terminale con lo stesso identico codice ... che appunto è quello che ci si aspetta (o meglio che io mi aspetto).

Questo comportamento, a mio parare, mina la credibilità di FPC su uno dei più importanti paradigmi della programmazione ad oggetti.

[cappe]

per non lo è, prova ad invertire

procedure A1(p: Integer); overload;
begin
  writeln('Integer');
end;

procedure A1(p: TColor); overload;
begin
  writeln('Color');
end;

[DragoRosso]

per non lo è, prova ad invertire .................

Cosa cambia ? Scriverà sempre Integer invece di TColor, ne sono abbastanza sicuro anche senza provare
Esattamente lo stesso bug.

Anzi è peggio, dimostrerebbe che in realtà il tipo "rilevato" è sempre uno solo OSSIA il primo che trova implementato in ordine nelle funzioni in overload (quindi da un verso sempre TColor e dall'altra sempre Integer), e quindi a maggior ragione dovrebbe generare un errore in compilazione.

Ammesso e non concesso che possa andare bene, avremmo due comportamenti diversi con le stesse identiche dichiarazioni.

Non penso che la definizione di overload debba avere una precedenza ... se no quale sarebbe quella giusta ?

[nomorelogic]

scusate...
ho letto nel forum internazionale ed ho provato a compilare il programma in questo thread
(che per sicurezza riporto)

però, a me da il risultato corretto.... 

Codice: [Seleziona]

program testover;

type
  TColor = -$7FFFFFFF-1..$7FFFFFFF;

const
  clmyRed: TColor = 255;

procedure A1(p: TColor); overload;
begin
  writeln('Color');
end;

procedure A1(p: Integer); overload;
begin
  writeln('Integer');
end;

var myint: integer;
begin
  myint := 87;
  A1(clmyRed);
  A1(myint);  //QUESTO dovrebbe chiamare la versione "Integer" non quella "Color" ...
  ReadLn;
end.

dopo averlo compilato con fpc 3.2.2, ho questo risultato:

Codice: [Seleziona]

$ ./test_over 
Color
Integer

Edit:
non capisco, voi che versione di fpc avete provato?

[DragoRosso]

Lazarus 4.6 fpc 3.2.2, però sono su Windows con compilatore a 64 bit.

[nomorelogic]

Ho provato su windows, compilatore fpc 3.2.2 64bit: quì ho riscontrato il bug.

Su Linux, stesso cpmpilatore fpc 3.2.2 64bit, come già accennato, il bug non si presenta.

Il problema sembrerebbe quindi localizzato sulla generazione del binario su OS Windows.

[DragoRosso]

Ho provato su windows, compilatore fpc 3.2.2 64bit: quì ho riscontrato il bug.
Su Linux, stesso cpmpilatore fpc 3.2.2 64bit, come già accennato, il bug non si presenta.
Il problema sembrerebbe quindi localizzato sulla generazione del binario su OS Windows.

Ma il codice binario riguardante quella parte non dovrebbe avere differenze, non ci sono di mezzo chiamate API. La "tipizzazione" e l'overload sono una caraterizzazione del compilatore e non dovrebbero dipendere dal sistema operativo (sicuramente nel caso si processore compatibile).
Se hai usato Linux su x86-64 e Windows su x86-64 questa cosa non dovrebbe accadere, ma potrebbe accadere su piattaforme completamente diverse, ad esempio su ARM o su codice a 32 bit ... questo si (rimane comunque un bug).

Questa cosa è preoccupante, perchè mette in dubbio su come il compilatore esegua la tipizzazione e l'overload. Non può scambiare fischi per fiaschi.
Nel forum hanno riportato altre prove, e sembra che una discriminante importante sia la "lunghezza" del "tipo", quindi tipi con lunghezza identica come in questo caso potrebbero "confondere" il compilatore.

Quello che non comprendo è che nessuno a dato peso più di tanto a questo aspetto.
Non voglio assolutamente denigrare FPC, sia chiaro, ma ritengo che questa cosa sia importante.

L'overload dei metodi sono fondamentali e li uso spessissimo, quindi avere un tarlo sismile per mè sarebbe un incubo. E' accaduto anche per Delphi quando sbagliò a compilare codice (solo a 64 bit) su una particolare funzione .... non vi dico gli incubi notturni e diurni per paura che il mio codice fosse affetto da tale problema .... perchè ho il vizio di aggiornare alla prima occasione tutti i prodotti ed i clienti e quindi avrei diffuso il "bug" a dismisura ...
Poi per fortuna dopo mal di testa e verifiche approfondite il mio codice non era affetto dal problema e ho tirato un sospiro di sollievo.

Ciò lo espongo solo per chiarificare il mio comportamento nel contesto.

[nomorelogic]

appena ho modo proverò a compilare sotto LInux qualche sorgente preso dal forum inglese
se avrò un binario corretto lo segnalerò anche a loro

[varianus]

Fa la stessa cosa anche con FPC 3.2.3 sotto Windows compilando a 32 bit.

Presumo che sia dovuto al fatto che usando la stessa rappresentazione il compilatore li consideri la stessa cosa.
Se forzo la clonazione del tipo

Codice: [Seleziona]

type
  TColor = type -$7FFFFFFF-1..$7FFFFFFF;  

funziona correttamente, almeno con la mia versione. E' la stessa cosa che hanno fatto per differenziare double e TDateTime.

I due tipi restano comunque compatibili a livello di assegnazione, come specificato nel wiki: https://wiki.freepascal.org/Type

[DragoRosso]

Fa la stessa cosa anche con FPC 3.2.3 sotto Windows compilando a 32 bit.
Presumo che sia dovuto al fatto che usando la stessa rappresentazione il compilatore li consideri la stessa cosa.
Se forzo la clonazione del tipo

Codice: [Seleziona]

type
  TColor = type -$7FFFFFFF-1..$7FFFFFFF;  

funziona correttamente, almeno con la mia versione. E' la stessa cosa che hanno fatto per differenziare double e TDateTime.
I due tipi restano comunque compatibili a livello di assegnazione, come specificato nel wiki: https://wiki.freepascal.org/Type

Quando si dichiara l'overload, questo deve funzionare correttamente, perchè io richiamo come parametro una variabile tipizzata, non un valore qualsiasi, come una costante literale dove si possono creare dubbi a runtime
E il fatto di definire il "range" di TColor come anch'esso un tipo è un sovrappiù (basterebbe anche solo il casting, che però non funziona comunque).

Senza il tuo "type", anche l'assegnazione, forse in questo caso funziona, ma avrei parecchi dubbi nel complesso (già esperienze negative simili in FPC):

- attiva il range checking e cambia il valore assegnato a myInt e il valore di clmyRed in $7FFFFFFE ->
 

Codice: [Seleziona]

myint := $7FFFFFFE;
.......
clmyRed: TColor = $7FFFFFFE; 

Esegui ... dovrebbe andare tutto bene.

Ora cambia il valore limite massimo di TColor in $7FFFFFFE  ->
 

Codice: [Seleziona]

 TColor = -$7FFFFFFF-1..$7FFFFFFE;

Esegui ...  errore nel range checking ?
Perchè ?

Se ci fosse un problema con i tipi, questo DEVE essere segnalato a livello di compilazione, ossia non posso assegnare pere con mele anche se entrambi si pesano sempre in grammi.

Ma se passa la compilazione e i valori limite rientrano nei range, perchè generare un errore a runtime?

Poi è ovvio che il range check nessuno le attiva, però ciò ti dà l'idea che qualcosa nel compilatore non gira nel verso giusto.

Ohh, magari sono io fissato. Però ....

Codice compelto con error checking

Codice: [Seleziona]

program testover;

{$mode Delphi}

type
  TColor = -$7FFFFFFF-1..$7FFFFFFE;

const
  clmyRed: TColor = $7FFFFFFE;

procedure A1(p: TColor); overload;
begin
  writeln('Color');
end;

procedure A1(p: Integer); overload;
begin
  writeln('Integer');
end;

var myint: integer;
begin
  myint := $7FFFFFFE;
  A1(clmyRed);
  A1(myint);   //QUESTO dovrebbe chiamare la versione "Integer" non quella "Color" ...
  ReadLn;
end.

[nomorelogic]

comunque leggendo sul forum inglese si vede che il problema sembra più che altro legato alla LCL (unit Graphics)
strano sul serio...