È normale per oggetti che hanno uno statorelativo a una risorsa non di memoria per fornire un metodo per "terminare" esplicitamente tale risorsa. Esiste una pratica comune preferita per affrontare il caso in cui viene tentata la deallocazione di un oggetto mentre si trova ancora nello stato "using my resource"? Ho visto un paio di approcci diversi:
- registra che il programmatore ha commesso un errore e spiega come eseguirne il debug (
NSLocklo fa) - lascia che il chiamante scelga se la risorsa è gestita dal chiamante o abbandonata sulla deallocazione (ad es.
NSFileHandle) - sollevare un'eccezione se l'oggetto non si trova in uno stato finale previsto, cioè asserire che il programmatore non utilizzerà il mio oggetto in quel modo
- pulisci sempre all'uscita.
Il Documenti GC conferma che la gestione di altre risorse insieme alla gestione della memoria è una cattiva idea e (ancora) fornisce un esempio di come fare 4, anche se con avvertimenti. Quindi qualcuno ha "scelto" un approccio da seguire sempre?
risposte:
1 per risposta № 1Poiché la maggior parte degli oggetti del framework Cocoa è precedenteGarbage Collection, non si può presupporre che NSFileHandle, ad esempio, stia facendo il modo migliore. Penso che questo problema sia uno dei tanti in cui ci piacerebbe avere uno schema da seguire per ogni scenario e salvarci il disturbo di fare una scelta. Sfortunatamente, non credo che sia possibile; dovrai determinare cosa è meglio, caso per caso.
Ecco i motivi per scegliere una delle tue opzioni:
- Se la pulizia automatica è ragionevolmente sicura, ma il programma dovrebbe davvero farlo manualmente.
- Se stai scrivendo una biblioteca e la risorsa può o non può essere di proprietà del tuo oggetto.
- Se la pulizia automatica non è possibile o in qualche modo rischiosa.
- Se la pulizia automatica è banale e non vale la pena di preoccuparsi di qualcuno per farlo manualmente.