Quote Originariamente inviata da Scara95 Visualizza il messaggio
La presenza di un GC introduce il problema opposto: non conoscere il lifetime degli oggetti. Questo nella maggior parte dei casi non ti da alcun problema, ma in presenza di risorse speciali che devi assicurarti di rilasciare sempre è un problema. Un esempio: se utilizzi un file all'interno di una funzione in C++ sarai sicuro che all'uscita dalla funzione il file sarà liberato, in C# e Java no. E' a questo scopo che nascono keywords quale using in C# che viene tradotta con un try-finally che si assicura che venga sempre chiamata la funzione .Dispose() che libera le risorse di fatto invalidando l'oggetto, ma senza distruggerlo (ovvero, l'oggetto rimane allocato, vengono solo liberate le risorse speciali).
A tal proposito, questo è un articolo che mi ha aperto gli occhi sul GC: in linea di principio, il punto del GC non è deallocare gli oggetti una volta che non sono più raggiungibili, ma simulare un computer con memoria infinita, in cui non hai bisogno di curarti della deallocazione degli oggetti, per cui, avendo sufficiente memoria a disposizione, il runtime potrebbe tranquillamente rimandare la distruzione di tutti gli oggetti fino alla fine del programma. Questo significa che per qualunque risorsa che non sia la memoria, devi comunque metterti in piedi sistemi come Using/IDisposable, with/__enter__/__exit__, try...finally & co.
@MItaly si può dire che il reference counting sia la più facile forma di GC, infatti basta scrivere una funzione che utilizzi per l'assegnazione e una funzione per scartare i valori di ritorno non utilizzati.
Questo assumendo non siano presenti cicli, in questo caso quegli oggetti rimarrebbero fino all'uscita, dove la memoria sarebbe comunque liberata dal sistema.
Sì, leggendo l'articolo su Wikipedia ho visto che il reference counting viene considerato tra i metodi di garbage collection, per qualche motivo l'ho sempre considerata una cosa a parte.