Free() vs FreeAndNil()

[Lorenzo]

Purtroppo essendo duro di comprendonio,non ho ancora compreso la netta differenza tra il metodo Free() e FreeAndNil()

Sono quando richiamiamo Free() da un oggetto(ad esempio obj.Free()),viene richiamato il costrutto e disallocato il relativo puntatore.
FreeAndNil(obj) si comporterebbe alla medesima maniera?

[DragoRosso]

Il metodo Free semplicemente libera le risorse dell'oggetto.

Ma la variabile che referenzia l'istanza dell'oggetto punta ancora alla vecchia istanza non più esistente.
Per terminare correttamente il tutto sarebbe necessario settare a NIL la variabile.

Il metodo FreeAndNil invece fà entrambe le cose, prima esegue il Free e poi pone a NIL la variabile.

Bisogna fare attenzione ad usare il FreeAndNil: ci sono delle classi che rilasciano le risorse non immediatamente, e non in maniera sincrona alla chiamata del FREE: una classe base tra le più note è il TThread, ma anche tutte le classi che hanno a che fare con le "comnuicazioni" come con i socket.

Porre a NIL una variabile relativa ad una istanza di un oggetto che non è ancora del tutto "liberata" non è detto generi per forza problemi, ma su quella istanza non si avrà alcun controllo e normalmente genererà un LEAK (ma non è detto).

Come sunto:
- FreeAndNil và bene in tutte la classi in genere, eccetto nella classi dove vengono gestiti eventi asincroni (come le comunicazioni appunto).
- Se non si usa FreeAndNil (quindi solo il FREE), sarebbe necessario porre a NIL la variabile per evitare errori di "ACCESS VIOLATION" successivi.

Se una classe figlia di un qualche controllo viene distrutta a "mano" dal nostro codice (senza metterla a NIL), è possibile che quando si eseguirà il free del controllo padre questo andrà in errore perchè il padre distrugge SEMPRE tutti i figli nel FREE e trovandosi ancora un riferimento che non è NIL cercherà di distruggerlo di nuovo.

Teoricamente tutti componenti forniti in bundle dall'ambiente sono protetti da questa eventualità in quanto eseguendo il FREE venogno tolti anche dall'elenco dei "figli", ma se costruite un serie di classi vostre la cosa potrebbe essere diversa.

[Mimmo]

Ciao, è come dice DragoRosso. In pratica entrambe deallocano l'istanza di un oggetto e liberano la memoria, solo che una fa anche l'assegnazione a nil del puntatore. La FreeAndNil è comoda negli algoritmi in cui ad esempio durante l'elaborazione fai dei check del tipo Assigned() magari perchè hai qualche lista di oggetti allocati alla bisogna (tipo caching) o se devi gestire un singleton, cose così. Ho il forte sospetto che sia nata per comodità o forse, per fpc, per compatibilità con Delphi.

[DragoRosso]

Io ho incominciato ad usare FreeAndNil appena "comparso", vedendolo come una panacea a tutti i mali.
Poi, con l'esperienza devo dire che di fatto ora non lo uso praticamente mai.

Una buona programmazione non ha necessità di usare tale "template", perchè in linea teorica il codice dovrebbe essere sotto il controllo completo e totale del programmatore. Quindi dovrei sapere se quella istanza è libera, già usata o altro senza bisogno di ausili esterni.
E attenzione: il fatto che in un qualsiasi punto del codice io non conosca i possibili stati reali di una qualsiasi istanza indica una cattiva programmazione.
Non è che inserendo alchimie che mi tolgono il pensiero da ciò ho creato un "buon" codice, anche se il codice magari funzionerà lo stesso senza alcun problema.

Io ad esempio preferisco usare nil prima di creare un oggetto (se ho dubbi sulla sua consistenza) e mettendo un "check" allert se la variabile è già istanziata (sia con un puntatore invalido che valido) in modo da segnalare eventuali anomalie.
Poi se non "escono fuori" sorprese con il tempo tolgo il "check".
Ma ripeto, ormai molto difficilmente mi accade di fare queste cose.
Anche il free lo uso molto di meno. Tendo a riusare i componenti quando possibile (e lo è nella stragrande maggioranza dei casi) e le interfacce.

Ma programmo in Delphi, dove alcuni concetti (o linee di pensiero) sono leggermente diversi da quelle di FPC.

Giusto per rallegrare l'argomento, vorrei ricordare che come tutti i codici sviluppati ci sono sempre possibilità di AV; se ad esempio in questa linea:

Codice Seleziona Espandi

FreeAndNil(MyObject);accadesse un eccezione, viene garantito che MyObject sia a NIL in ogni caso.

In questo codice

Codice Seleziona Espandi

MyObject.Free;
MyObject := nil;no, se accade una eccezione durante l'esecuzione del metodo FREE, la variabile non verrà posta a NIL e potrebbe esserci un rischio di un AV futuro nel caso si tenti di usare qualcosa tipo

Codice Seleziona Espandi

If assigned(MyObject) then
  MyObject.Free
Ma queste sono sottigliezze, casi teorici che difficilmente si verificano.
Lo indico qui solo per fini divulgativi.

[Lorenzo]

@DragoRosso e @Mimmo
Vi ringarzio per i vostri interventi.
@Mimmo,fatto benissimo a tirare fuori il confronto con Delphi.
@DragoRosso, mi spice di non dare una meriterovele risposta articolata all'ottimo post.
Io mi sono visto costretto a usare il settaggio di variabile puntatore a nil per non incorrere più nel classico errore General Protection Fault che mi sembra quel classico errore generato dal debug quando si imbatte in "cadaveri".

Sui template sono al 100% d'accordo e su questa linea di ragionamento che non riesco a vedere di buon occhio la IA.