[C#/VB.NET] Impostare valori a Nothing (null) e relativa utilità

[cassano]

io per nn sbagliare faccio sempre il
dispose seguito dal nothing.

[99eros9]

Bisogna vedere anche se si stà parlando di risorse gestite o di risorse non gestite, e comunque non mi sembra di aver letto da nessuna parte la raccomandazione di impostare un riferimento a nothing visto che l'uscita dall'ambito viene decretata da un azione del puntatore allo stack dove si trova il riferimento all'oggetto. Quanto meno penso che sia così, lasciando da parte i distruttori.

[alka]

Originariamente inviato da vaitrafra
oddio, inutile, prima di downgradare a VB6 causa cambio lavoro usavo spesso nothing per azzerare miei oggetti. Ci sono diversi ambiti di utilità di nothing... quello che mi viene in mente sul momento è lo scatenare eventi in base allo stato di un'oggetto.

Come ho scritto in una precedente risposta, "a meno che non ci siano motivi logici"...

Ovvio che se voglio attribuire un significato specifico al Nothing, devo utilizzare quel valore ed impostarlo se necessario, ma lo si fa per un motivo di logica dell'applicazione, non inerente al meccanismo di rilascio della memoria allocata.

Originariamente inviato da vaitrafra
se in un tuo percoso applicativo un'oggetto è istanziato nello scope di una funzione che richiama altre 80 funzioni nestate, Settarlo a nothing prima o dopo una determinata istruzione direi che velocizza il risucchio di quest'ultimo da parte del GC...non mi sono spiegato lo so, ma fa lo stesso.

Se il valore viene sostituito da un altro nelle "funzioni nestate", mi sembra una fatica inutile: quando la variabile assume il riferimento ad un altro oggetto, l'altro verrà considerato come "papabile di Garbage Collection", tanto quanto avviene quando lo metti a Nothing.


Il fattore che volevo sottolineare io è un altro, più concettuale che pratico (proprio per questo presumo che non vi sia uno schema fisso in merito, come si può facilmente evincere da qualche semplice ricerca su Internet). Io parto dal presupposto che il GC svolga correttamente il proprio lavoro e che il codice debba concentrarsi il più possibile sull'aspetto logico del proprio compito, evitando il più possibile "escamotage architetturali"; piuttosto che riempire una routine di impostazioni a null di questo o quell'altro riferimento, farei più attenzione alla suddivisione logica del programma, ad adottare costrutti using dove richiesto, a scegliere la classe giusta per lo scopo giusto evitando decadimento di performance e così via.

In fondo, si sta sempre utilizzando un ambiente gestito con un Garbage Collector.
Preoccuparsi di "costellare" il codice di Nothing quando, poi, i meccanismi interni che determinano il rilascio della memoria sono sconosciuti, poiché non ci troviamo in un sistema deterministico, appunto, mi sembra un po' una contraddizione o comunque una pratica soggetta alla concezione che si ha dello strumento.

Se voglio avere il controllo della memoria allocata, allora non forzo riferimenti a null seguiti da chiamate a GC.Collect e così via, uso direttamente un altro ambiente di sviluppo e linguaggio che forniscano queste possibilità senza bisogno di riempire il codice di "escamotage".

O almeno, questo è il mio punto di vista personale.

Ciao!

[99eros9]

In realtà si può implementare codice unsafe e utilizzare i puntatori, ma a quel punto si perde la capacita del GC di ricompattare l'heap gestito.

[alka]

Originariamente inviato da 99eros9
In realtà si può implementare codice unsafe e utilizzare i puntatori, ma a quel punto si perde la capacita del GC di ricompattare l'heap gestito.

Idem come sopra: se devo usare .NET per scrivere un'applicazione con gestione della memoria interamente affidata a codice unsafe, lascio perdere, o in ogni caso ci si sta addentrando in un ambito molto specifico.

Ciao!