ULTERIORE BUG ??? O MIA IGNORANZA ABISSALE ???

[DragoRosso]

Usando parte del codice di un precedente post, ho provato ulteriori "questioni" a riguardo delle istanze degli oggetti ... e venendomi un terribile dubbio ho osato qualcosa che non mi sarei mai sognato di fare ... questo è il codice, che viene eseguito senza alcun problema (ossia compare lo showmessage) senza generare mai errore ........ ecco in questi momenti mi viene, nonostante la veneranda età, ancora da piangere e la vita mi scorre davanti agli occhi ..... con un teschio come immagine finale .....

Nuovo preogetto, mettete sempre un pulsante con l'evento OnCLick e poi sovrascrivete tutto con il codice seguente ... 

Codice: [Seleziona]

unit Unit1;

{$mode objfpc}{$H+}

interface

uses
  Windows, Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls;

type
  TDoSomething = class
    Danger: string;
    constructor create;
    procedure FaiQualcosa;
  end;

type

  { TForm1 }

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private

  public

  end;

var
  Form1: TForm1;
  DoSomething: TDoSomething;

implementation

{$R *.lfm}

constructor TDoSomething.create;
begin
  //DI QUI NON CI PASSO MAI .... E SE CI PASSASSI PER SBAGLIO CHIUDO IL PROGRAMMA !!!
  ExitProcess(0);
  Danger := 'Danger!';
end;

procedure TDoSomething.FaiQualcosa;
begin
  ShowMessage('Faccio qualcosa');
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  DoSomething.FaiQualcosa;
end;

end.

Posto anche le due immagini dell'esecuzione .... qualcuno mi dica (a parte che ripeto non farei mai una cosa simile coscentemente) che ho le travegole ...

Avete notato cosa manca ? No ..... non c'è la creazione dell'istanza (di DoSomething), ma il codice viene eseguito lo stesso .... 

......

[DragoRosso]

Aggiungo un commento giusto per buttarla in ridere .... tempo fà avevamo parlato dei NULL RECORD (TNullable) su dei post .... ecco quello sopra invece è un ottimo esempio di  .... NULL CLASS.

  ... sigh

[nomorelogic]

in effetti è un comportamento abbastanza assurdo

ho fatto una prova modificando questo codice

Codice: [Seleziona]

ShowMessage('Faccio qualcosa ' + Danger);

ed in effetti così c'è un errore a runtime
mi viene da pensare che in questi casi il metodo chiamato si comporti come fosse un class method
ma chiaramente nessuno glielo ha chiesto...

[DragoRosso]

Bhè, almeno quello funziona. Una stringa deve avere un blocco di memoria allocata ..... certo qualcuno direbbe anche un pezzo di codice dovrebbe averlo, e a maggior ragione 

Class Method neanche tanto, sono convinto che andando a fondo se ne scoprirebbero altre, ma ho paura di proseguire 

Però, mal comune mezzo gaudio, anche in Delphi il comportamento è identico. Non sò se aprire un "incidente" presso Emb ... mi sà di si ... li pago e che cavolo ....

Intanto posto su Praxis e mi becco 1000 insulti dai suoi membri .....

Ciao

[nomorelogic]

beh...
segnalalo sul forum ufficiale di Fazarus, li è gratis...
 

[DragoRosso]

Risposta già avuta: secondo uno dei membri del forum, i metodi sono comunque routine "statiche" in cui il primo argomento "nascosto" è SELF. Se non si usa SELF, o chiaramente altri membri "managed" come le stringe ..... si possono chiamare anche se l'oggetto non è istanziato.

E ha fatto l'esempio di un oggetto dichiarato all'interno di una procedura (quindi locale) non istanziato nè inizializzato, quindi NON NIL.

Il metodo viene chiamato ed eseguito correttamente.

Secondo lui è normale e deve essere così; pensandoci bene in effetti come ragionamento ci stà.

Oggi è stato minato un bel pezzo di certezza sula programmazione, certo magari "certezza" su basi non così solide, però ...

Ciao

[nomorelogic]

se hai modo riporta il link, così chi vuole può documentarsi e/o partecipare all'altra discussione

[DragoRosso]

Certo, questo è il link: https://en.delphipraxis.net/topic/6615-class-not-instantiated-but-method-executed/

Guardate anche il link inserito da Dalija Prasnikar che è interessante.

Sunto del tutto è che è corretto quello che accade, perchè i metodi di una classe che non accedono alle risorse della stessa classe sono definiti statici per progettazione (parlano della caratteristica del linguaggio di programmazione).

Essendo statici possono essere chiamati anche da "oggetti" non istanziati a NIL o adirittura da oggetti "sporchi" come quelli dichiarati come variabili locali.

Ovviamente, fpc che clona Delphi ha le stesse caratteristiche.

Io, nonostante le spiegazioni, ritengo che tale soluzione non sia la più pulita. Per essere statici i metodi dovrebbero essere dichiarati esplicitamente statici. E l'uso di una istanza a NIL dovrebbe generare un errore runtime. Comunque tant'e, le cose stanno in cotale situazione. L'importante è saperlo affinchè si possano prendere le opportune misure.

Ciao

[Stilgar]

Come ti ho detto in privato, quello è un metodo "statico mascherato"


Definizione tanto al chilo per capirsi.


Stilgar

[SB]

Probabilmente sto diventando troppo vecchio, ma non capisco dove sia il problema
Provo a dire due parole in base alle mie conoscenze

Nella programmazione a oggetti il codice e i dati sono separati. Il codice esiste anche se non si sono creati oggetti.
Gli oggetti altro non sono che aree di memoria allocate e le variabili di tipo oggetto contengono puntatori a queste aree.
Un puntatore è solo un numero e viene passato come parametro nascosto ai metodi degli oggetti valorizzando la variabile Self
Se chiamo un metodo di un oggetto non istanziato il codice viene eseguito comunque. Semplicemente opera con un'area di memoria "casuale" ("sporca") dove i valori che trova possono a volte essere interpretati come validi e a volte essere interpretati malamente. In questo caso può tentare di accedere ad aree di memoria non allocata o protetta e il gestore della memoria virtuale del sistema operativo interviene segnalando una eccezione

La differenza tra metodi statici (di classe o come altro si vuole chiamare) e metodi "normali" è solo a livello di linguaggio/compilatore nella modalità di chiamata e nel parametro "nascosto" che può esserci o meno.
Per il resto è codice normale

Chiamare un metodo attraverso un oggetto non istanziato è sintatticamente corretto anche se semanticamente errato. Il codice viene eseguito, anche se su un'area di memoria non valida
Non si possono mettere controlli sulla validità dei puntatori a livello di esecuzione. Prima di tutto sarebbe troppo pesante controllare ogni chiamata. E, cosa forse più importante, il compilatore dovrebbe riuscire a "capire" il codice (impossibile) perchè le possibili variazioni sono davvero infinite.
Per questo hanno inventato, ad esempio, il linguaggio Rust che obbliga il programmatore a dichiarare le proprie intenzioni e lo costringe a scrivere codice che non può generare problemi (con un prezzo da pagare non indifferente).

[Stilgar]

SB, in parte condivido il tuo pensiero.
Mi sento di fare una piccola precisazione sul codice generato da FPC sui metodi statici/di classe.


Il metodo statico ha due caratteristiche che lo differenziano da quello non statico, almeno per quello che ci interessa in questa chiacchierata.


Il metodo statico non deve accedere a nessuna definizione della classe che abbia a che fare con una istanza (progettazione).
Non viene "passato il puntatore all'istanza" (costruzione stack a livello di chiamata).


Se un metodo normale non fa accesso a nessuna definizione di istanza, di fatto gli viene passato un puntatore che nella sostanza è solo una cosa scritta nello stack per sport.
Nel momento in cui viene eseguito un accesso ad una qualsiasi definizione (metodo/property/attributo) di una instanza, gli errori scattano eccome, se il self non è valorizzato correttamente.

Non si possono mettere controlli sulla validità dei puntatori a livello di esecuzione. Prima di tutto sarebbe troppo pesante controllare ogni chiamata.

Forse non ho inteso correttamente cosa intendevi sul controllare ogni accesso, ma mi sentirei di smentire la tua ipotesi.


Se fai una prova veloce, in un metodo usi solo un writeln("Statico mascherato") e in un altro stampi un attributo dell'istanza vedrai che ti escono fuori i petardi a console. Di conseguenza il codice generato rispetta le prerogative della programmazione ad oggetti.


Con Drago c'è stata una chiacchierata in merito perché diceva essere un comportamento che non capiva e trovava errato. Secondo lui avrebbero dovuto mettere i controlli prima di eseguire la call e non dentro il metodo.
Di suo è un modo di scrivere codice che ritengo da mettere nelle cattive pratiche. Da lì il nomignolo.


Stilgar

[DragoRosso]

Volevo solo precisare alcuni concetti:

il fatto che un metodo di una classe venga eseguito comunque sai esso statico o no è comunque secondo mè discutibile.
Innanzitutto un metodo dovrebbe essere dichiarato statico esplicitamente, e solo questo dovrebbe essere eseguito su una istanza a nil.

Eseguire una procedura o funzione con il "padre" a nil indica che posso fare diverse cose (per estensione "danni") prima di accorgermi di accedere a qualcosa che non esiste, perchè magari la prima parte di codice non accede ai dati della classe, poi quando vi accede verrà generata una eccezione .... però intanto ho già eseguito qualcosa .....

E' per questo che è necessario che un metodo venga sempre seguito (indipendentemente dal "padre") se è ESPLICITAMENTE statico, se invece non lo è andrebbe verificato che l'istanza esista (ad esempio se l'istanza è allocata in una apposita tabella).

Io controllo a codice se la creazione dell'istanza ha avuto un risultato, ma non è pensabile che ad ogni chiamata di funzione o altro debba controllare esplicitamente a codice se l'istanza esiste ....

Su questo discuto. E' un problema anche di sicurezza: chi vorrebbe che una qualsiasi classe possa "funzionare" anche se non istanziata, magari per un errore del codice (o per una qualsiasi causa non prevista dal programmatore) ?

Chi parla di puntatori e altro probabilmente proviene dal C (come anche io), ed è abituato a lavorare con questi. Nel forum ho fatto più volte esempi su come si possa violare costrutti e definizioni usando i puntatori in maniera furba, senza che alcuna eccezione venga generata ... ma questo non è e non dovrebbe essere Pascal.

Dobbiamo pensare ad un altro livello, il Pascal è un linguaggio che non può lasciare spazio a problemi simili, ancorchè questi siano difficili da rilevare.

Io proporrei che il compilatore inserisca il controllo esplicito, e aggiungerei uno switch in compilazione che escluda  questo extra codice del compilatore per queste "verifiche": potrebbe essere una soluzione (ad esempio nelle parti di codice critiche per la "velocità" di esecuzione).

SB, in parte condivido il tuo pensiero.

Non si possono mettere controlli sulla validità dei puntatori a livello di esecuzione. Prima di tutto sarebbe troppo pesante controllare ogni chiamata.

Forse non ho inteso correttamente cosa intendevi sul controllare ogni accesso, ma mi sentirei di smentire la tua ipotesi.
....

Penso che @SB si riferisca alla protezione in esecuzione del codice, ossia che a runtime sia controllato (come in questo caso) che il puntatore abbia un qualche riferimento ("padre" ad esempio) valido.

EDIT: intendo un controllo hardware che verifichi che il codice che stò per eseguire "appartenga" ad una classe istanziata, "definizione" che non appartiene ai processori (non conoscono il concetto di "oggetti" e "istanze"). E' ovvio che l'accesso a zone di memoria di qualsiasi tipo sono invece controllate in hardware (come di fatti avviene se accedo a delle "memorie" non allocate).

Mancando a livello di processore una qualche forma di protezione (se non quella basilare di aree di memoria R / W / X) su quest'argomento, tale funzione dovrebbe essere fornita dal compilatore con un extra codice che inciderebbe sia sul tempo di esecuzione che sulla lunghezza del codice.

Arriverà comuqnue in ns. aiuto in un futuro (esiste già, ma solo il compilatore Microsoft lo implementa) la tecnologia CodeGuard (CGF) che non risolve in toto la problematica ma un pezza ce la mette (e può essere anche selettiva).

Non essendo comunque un ingenere ne di microcodice ne di compilatori, ovviamente mi adeguo a quanto c'è. Fortunatamente, sino a gualche giorno fà ero ignaro della cosa e i programmi che ho sempre sviluppato non hanno (non dovrebbero avere  ) problematiche di quel tipo.

Ciao

[Stilgar]

Il controllo via micro dovrebbe essere implementato.
O almeno così mi vien da pensare leggendo i problemi che hanno con AIX e il fatto che non riuscivano a far scattare il "Nil Pointer" per l'architettura del SO.


Poi non essendo dentro il core team potrei prendere una cantonata.


Stilgar