In lingue come C, il programmatore dovrebbe inserire chiamate gratuitamente. Perché il compilatore non lo fa automaticamente? Gli umani lo fanno in un ragionevole lasso di tempo (ignorando i bug), quindi non è impossibile.

EDIT: per riferimento futuro, ecco un'altra discussione che ha un esempio interessante.

Perché non è possibile stabilire se il programma utilizzerà nuovamente la memoria. Ciò significa che nessun algoritmo può determinare correttamente quando chiamare free()in tutti i casi, il che significa che qualsiasi compilatore che ha tentato di farlo produrrebbe necessariamente alcuni programmi con perdite di memoria e / o alcuni programmi che hanno continuato a utilizzare la memoria che era stata liberata. Anche se hai assicurato che il tuo compilatore non ha mai fatto il secondo e hai permesso al programmatore di inserire chiamate per free()correggere quei bug, sapere quando chiamare free()quel compilatore sarebbe ancora più difficile che sapere quando chiamare free()quando si utilizza un compilatore che non ha provato aiutare.

Come ha giustamente sottolineato David Richerby, il problema è ineccepibile in generale. La vivacità degli oggetti è una proprietà globale del programma e può in generale dipendere dagli input del programma.

Anche la raccolta dei rifiuti dinamica precisa è un problema indecidibile! Tutti i garbage collector del mondo reale usano la raggiungibilità come approssimazione conservativa sulla necessità o meno di un oggetto assegnato in futuro. È una buona approssimazione, ma è comunque un'approssimazione.

Ma questo è vero solo in generale. Uno dei più famosi cop-out nel settore dell'informatica è "è impossibile in generale, quindi non possiamo fare nulla". Al contrario, ci sono molti casi in cui è possibile fare qualche passo avanti.

Le implementazioni basate sul conteggio dei riferimenti sono molto simili a "il compilatore che inserisce le deallocazioni" in modo tale che è difficile dire la differenza. Il conteggio automatico dei riferimenti di LLVM (usato in Objective-C e Swift ) è un famoso esempio.

Inferenza della regione e raccolta dei rifiuti in fase di compilazione sono le aree di ricerca attualmente attive. Risulta molto più facile in linguaggi dichiarativi come ML e Mercury , dove non è possibile modificare un oggetto dopo che è stato creato.

Ora, sul tema degli umani, ci sono tre modi principali in cui gli umani gestiscono manualmente le allocazioni:

1. Comprendendo il programma e il problema. Gli esseri umani possono mettere oggetti con vite simili nello stesso oggetto di allocazione, per esempio. Compilatori e netturbini devono dedurlo, ma gli esseri umani hanno informazioni più precise.
2. Utilizzando selettivamente la contabilità non locale (ad es. Conteggio dei riferimenti) o altre tecniche di allocazione speciali (ad es. Zone) solo quando necessario. Ancora una volta, un essere umano può sapere questo dove un compilatore deve dedurlo.
3. Male. Tutti sanno dei programmi distribuiti nel mondo reale che hanno perdite lente, dopo tutto. O in caso contrario, a volte i programmi e le API interne devono essere ristrutturati in base alla durata della memoria, riducendo la riusabilità e la modularità.

È un problema di incompletezza, non un problema di indecidibilità

Mentre è vero che il posizionamento ottimale delle dichiarazioni di deallocazione è indecidibile, questo non è semplicemente il problema qui. Poiché è indecidibile sia per gli umani che per i compilatori, è impossibile selezionare sempre consapevolmente il posizionamento ottimale della deallocazione, indipendentemente dal fatto che si tratti di un processo manuale o automatico. E poiché nessuno è perfetto, un compilatore sufficientemente avanzato dovrebbe essere in grado di superare le prestazioni umane nell'ipotesi di posizionamenti approssimativamente ottimali. Quindi, l' indecidibilità non è il motivo per cui abbiamo bisogno di dichiarazioni esplicite di deallocazione .

Ci sono casi in cui le conoscenze esterne informano il posizionamento delle dichiarazioni di deallocazione. Rimuovere tali affermazioni equivale quindi a rimuovere parte della logica operativa e chiedere a un compilatore di generare automaticamente quella logica equivale a chiedergli di indovinare cosa stai pensando.

Ad esempio, supponiamo che tu stia scrivendo un Read-Evaluate-Print-Loop (REPL) : l'utente digita un comando e il tuo programma lo esegue. L'utente può allocare / deallocare la memoria digitando i comandi nel proprio REPL. Il codice sorgente specifica cosa dovrebbe fare il REPL per ogni possibile comando utente, inclusa la deallocazione quando l'utente digita il comando per esso.

Ma se il codice sorgente C non fornisce un comando esplicito per la deallocazione, il compilatore dovrebbe dedurre che dovrebbe eseguire l'ubicazione quando l'utente immette il comando appropriato nel REPL. Quel comando è "deallocare", "libero" o qualcos'altro? Il compilatore non ha modo di sapere quale vuoi che sia il comando. Anche se programmate in logica per cercare quella parola di comando e REPL la trova, il compilatore non ha modo di sapere che dovrebbe rispondere ad essa con deallocazione a meno che non lo dica esplicitamente nel codice sorgente.

tl; dr Il problema è che il codice sorgente C non fornisce al compilatore conoscenze esterne. L'indecidibilità non è il problema perché è lì se il processo è manuale o automatizzato.

Attualmente, nessuna delle risposte pubblicate è completamente corretta.

Perché i compilatori non inseriscono automaticamente deallocazioni?

1. Alcuni lo fanno. (Spiegherò più tardi.)

2. In pratica, puoi chiamare free()subito prima che il programma si concluda. Ma c'è una necessità implicita nella tua domanda di chiamare free()il prima possibile.

3. Il problema di quando chiamare free()un programma C non appena la memoria è irraggiungibile è indecidibile, vale a dire per qualsiasi algoritmo che fornisce la risposta a tempo finito, c'è un caso che non copre. Questo - e molte altre indecidibilità di programmi arbitrari - possono essere provati dal problema dell'arresto .

4. Un problema indecidibile non può sempre essere risolto a tempo finito da nessun algoritmo, sia esso un compilatore o un essere umano.

5. Gli umani (provano a) scrivere in un sottoinsieme di programmi C che possono essere verificati per la correttezza della memoria dal loro algoritmo (loro stessi).

6. Alcune lingue ottengono il n. 1 costruendo il n. 5 nel compilatore. Non consentono programmi con usi arbitrari di allocazione della memoria, ma piuttosto un sottoinsieme decidibile di essi. Foth e Rust sono due esempi di linguaggi che hanno allocazioni di memoria più restrittive rispetto a quelle di C malloc(), che possono (1) rilevare se un programma è scritto al di fuori del loro insieme decidibile (2) inserire automaticamente deallocazioni.

"Gli umani lo fanno, quindi non è impossibile" è un errore ben noto. Non capiamo necessariamente (per non parlare del controllo) le cose che creiamo: il denaro è un esempio comune. Tendiamo a sopravvalutare (a volte in modo drammatico) le nostre possibilità di successo in materia tecnologica, specialmente quando i fattori umani sembrano assenti.

Le prestazioni umane nella programmazione del computer sono molto scarse e lo studio dell'informatica (carente in molti programmi di educazione professionale) aiuta a capire perché questo problema non ha una soluzione semplice. Potremmo un giorno, forse non troppo lontano, essere sostituiti dall'intelligenza artificiale sul posto di lavoro. Anche allora, non ci sarà un algoritmo generale che ottiene la deallocazione corretta, automaticamente, sempre.

La mancanza di gestione automatica della memoria è una caratteristica della lingua.

C non dovrebbe essere uno strumento per scrivere facilmente il software. È uno strumento per far fare al computer qualunque cosa tu gli dica di fare. Ciò include l'allocazione e la deallocazione della memoria al momento della tua scelta. C è un linguaggio di basso livello che usi quando vuoi controllare il computer con precisione, o quando vuoi fare le cose in un modo diverso da quello che i progettisti di librerie linguistiche / standard si aspettavano.

Il problema è principalmente un artefatto storico, non un'impossibilità di implementazione.

Il modo in cui la maggior parte dei compilatori C genera codice è che il compilatore vede solo ogni file sorgente alla volta; non vede mai l'intero programma contemporaneamente. Quando un file di origine chiama una funzione da un altro file di origine o una libreria, tutto il compilatore vede è il file di intestazione con il tipo restituito della funzione, non il codice effettivo della funzione. Ciò significa che quando esiste una funzione che restituisce un puntatore, il compilatore non ha modo di sapere se la memoria a cui punta il puntatore deve essere liberata o meno. Le informazioni per decidere che non vengono mostrate al compilatore in quel momento. Un programmatore umano, dall'altra parte, è libero di cercare il codice sorgente della funzione o la documentazione per scoprire cosa bisogna fare con il puntatore.

Se guardi a linguaggi di basso livello più moderni come C ++ 11 o Rust, scoprirai che hanno risolto il problema principalmente rendendo esplicita la proprietà della memoria nel tipo di puntatore. In C ++ userete un unique_ptr<T>invece di un piano T*per contenere la memoria e unique_ptr<T>assicuratevi che la memoria venga liberata quando l'oggetto raggiunge la fine dell'ambito, a differenza del piano T*. Il programmatore può passare la memoria l'uno unique_ptr<T>dall'altro, ma può essercene solo uno che unique_ptr<T>punta alla memoria. Quindi è sempre chiaro chi possiede la memoria e quando deve essere liberata.

C ++, per motivi di compatibilità con le versioni precedenti, consente ancora la gestione manuale della memoria vecchio stile e quindi la creazione di bug o modi per aggirare la protezione di a unique_ptr<T>. Rust è ancora più rigoroso in quanto applica regole di proprietà della memoria tramite errori del compilatore.

Per quanto riguarda l'indecidibilità, il problema di arresto e simili, sì, se si attesta la semantica C non è possibile decidere per tutti i programmi quando liberare la memoria. Tuttavia, per la maggior parte dei programmi attuali, non per esercizi accademici o software difettosi, sarebbe assolutamente possibile decidere quando liberare e quando non farlo. Dopo tutto, questo è l'unico motivo per cui l'essere umano può capire quando liberarsi o meno in primo luogo.

Altre risposte si sono concentrate sulla possibilità di eseguire la raccolta dei rifiuti, alcuni dettagli su come è stato fatto e alcuni dei problemi.

Un problema che non è stato ancora affrontato è l'inevitabile ritardo nella raccolta dei rifiuti. In C, quando un programmatore chiama free (), quella memoria è immediatamente disponibile per il riutilizzo. (Almeno in teoria!) Quindi un programmatore può liberare la propria struttura da 100 MB, allocare un'altra struttura da 100 MB un millisecondo dopo, e aspettarsi che l'utilizzo complessivo della memoria rimanga lo stesso.

Questo non è vero con Garbage Collection. I sistemi di raccolta dati inutili hanno qualche ritardo nel restituire la memoria non utilizzata all'heap e questo può essere significativo. Se la struttura da 100 MB non rientra nell'ambito di applicazione e dopo un millisecondo il programma imposta un'altra struttura da 100 MB, è ragionevole aspettarsi che il sistema utilizzi 200 MB per un breve periodo. Quel "breve periodo" può essere millisecondi o secondi a seconda del sistema, ma c'è ancora un ritardo.

Se stai usando un PC con concerti di RAM e memoria virtuale, ovviamente non lo noterai mai. Se stai utilizzando un sistema con risorse più limitate (ad esempio, un sistema incorporato o un telefono), questo è qualcosa che devi prendere sul serio. Questo non è solo teorico - l'ho visto personalmente creare problemi (come nel crash del tipo di problemi del dispositivo) quando si lavora su un sistema WinCE usando .NET Compact Framework e si sviluppa in C #.

La domanda presume che una deallocazione sia qualcosa che il programmatore dovrebbe dedurre da altre parti del codice sorgente. Non è. "A questo punto del programma, il riferimento di memoria FOO non è più utile" sono le informazioni conosciute solo nella mente del programmatore fino a quando non sono codificate (in linguaggi procedurali) una dichiarazione di deallocazione.

Non è teoricamente diverso da qualsiasi altra riga di codice. Perché i compilatori non inseriscono automaticamente "A questo punto nel programma, controllare il registro BAR per input" o "Se la chiamata di funzione restituisce un valore diverso da zero, uscire dalla subroutine corrente" ? Dal punto di vista del compilatore il motivo è "incompletezza", come mostrato in questa risposta . Ma qualsiasi programma soffre di incompletezza quando il programmatore non gli ha detto tutto quello che sa.

Nella vita reale, le deallocazioni sono lavori grugniti o scaldabagni; i nostri cervelli li riempiono automaticamente e si lamentano, e il sentimento "il compilatore potrebbe farlo altrettanto bene o meglio" è vero. In teoria, tuttavia, non è così, anche se fortunatamente altre lingue ci offrono una maggiore scelta della teoria.

Cosa viene fatto: esiste la garbage collection e ci sono compilatori che utilizzano il conteggio dei riferimenti (Objective-C, Swift). Quelli che fanno il conteggio dei riferimenti hanno bisogno dell'aiuto del programmatore evitando cicli di riferimento forti.

La vera risposta al "perché" è che gli autori di compilatori non hanno trovato un modo abbastanza buono e abbastanza veloce da renderlo utilizzabile in un compilatore. Dato che gli autori di compilatori sono in genere piuttosto intelligenti, potresti concludere che è molto, molto difficile trovare un modo che sia abbastanza buono e abbastanza veloce.

Uno dei motivi per cui è molto, molto difficile è ovviamente che è indecidibile. In informatica, quando parliamo di "decidibilità" intendiamo "prendere la decisione giusta". I programmatori umani possono ovviamente decidere facilmente dove collocare la memoria, perché non si limitano alle decisioni corrette . E spesso prendono decisioni sbagliate.

In lingue come C, il programmatore dovrebbe inserire chiamate gratuitamente. Perché il compilatore non lo fa automaticamente?

Perché la durata di un blocco di memoria è una decisione del programmatore, non del compilatore.

Questo è tutto. Questo è il progetto di C. Il compilatore non può sapere quale fosse l'intenzione di allocare un blocco di memoria. Gli umani possono farlo, perché conoscono lo scopo di ogni blocco di memoria e quando questo scopo viene servito, così può essere liberato. Fa parte del progetto del programma in fase di scrittura.

C è un linguaggio di basso livello, quindi i casi di passaggio di un blocco della memoria a un altro processo o persino a un altro processore sono abbastanza frequenti. In casi estremi, un programmatore può allocare intenzionalmente un pezzo di memoria e non riutilizzarlo mai più solo per esercitare pressione sulla memoria su altre parti del sistema. Il compilatore non ha modo di sapere se il blocco è ancora necessario.

In lingue come C, il programmatore dovrebbe inserire chiamate gratuitamente. Perché il compilatore non lo fa automaticamente?

In C e in molte altre lingue, c'è davvero una possibilità per fare in modo che il compilatore faccia l'equivalente di questo nei casi in cui è chiaro al momento della compilazione quando dovrebbe essere fatto: l'uso di variabili di durata automatica (cioè normali variabili locali) . Il compilatore è responsabile di disporre di spazio sufficiente per tali variabili e di rilasciare tale spazio al termine della loro (ben definita) durata.

Con le matrici a lunghezza variabile che sono una caratteristica C dal C99, gli oggetti a durata automatica servono, in linea di principio, sostanzialmente tutte le funzioni in C che fanno gli oggetti allocati dinamicamente di durata calcolabile. In pratica, ovviamente, le implementazioni in C possono porre limiti pratici significativi sull'uso dei VLA - cioè le loro dimensioni possono essere limitate a causa dell'allocazione in pila - ma questa è una considerazione di implementazione, non una considerazione di progettazione del linguaggio.

Quegli oggetti il ​​cui uso previsto impedisce di dare loro una durata automatica sono precisamente quelli la cui durata non può essere determinata al momento della compilazione.