Domanda

La regola generale, solo oggetti allocati nella memoria dinamica può causare perdite di memoria. Ma gli oggetti creati nello stack che non funziona.

Ecco il mio dubbio,

int main()
    {
      myclass x;

      ...

      throw;

      ...
    }

Se un tiro non viene gestita, si chiama, terminate (), che a sua volta chiama abort () e si blocca l'applicazione. In questo momento, gli oggetti nello stack non sono Destoryed (Il distruttore non viene richiamato).

La mia comprensione è "Quando l'applicazione termina (o di interruzione o di uscita normale), libera tutta la memoria che è stato assegnato per l'applicazione". Così questo non può essere considerato come perdita di memoria.

Ho ragione?

È stato utile?

Soluzione

In un ambiente di hosting (ad es il tipico Unix / Windows / Mac OS X, anche DOS, macchina) quando l'applicazione termina tutta la memoria che occupava viene recuperato automaticamente dal sistema operativo. Pertanto, non ha senso preoccuparsi di queste perdite di memoria.

In alcuni casi, prima di un termina applicazione, si consiglia di rilasciare tutta la memoria dinamica allocata al fine di rilevare eventuali perdite di memoria attraverso un rilevatore di perdite, come valgrind . Tuttavia, anche in questo caso una, l'esempio che descrivi non sarebbe considerato una perdita di memoria.

In generale, non riuscendo a chiamare un distruttore non è la stessa causando una perdita di memoria. perdite di memoria derivano dalla memoria allocata sul mucchio (con nuove o malloc o contenitori allocatori). Memoria allocata sulla pila viene recuperato automaticamente quando la pila è svolto. Tuttavia, se un oggetto contiene qualche altra risorsa (ad esempio un file o un handle di finestra), non riuscendo a chiamare il suo distruttore chiamerà una perdita di risorse, che può anche essere un problema. Anche in questo caso, moderna sistemi operativi sarà recuperare le loro risorse quando un'applicazione termina.

Altri suggerimenti

modifica: come detto da Gman, "buttare"; ri-genera un'eccezione precedentemente lanciata, o se non c'è nessuno, termina immediatamente. Poiché non v'è nessuno in questo caso, la risoluzione immediata è il risultato.

Chiusura di un processo sempre pulisce qualsiasi residuo userland di memoria in qualsiasi sistema operativo moderno, quindi non è in genere considerato un "perdita di memoria", che è definito come la memoria senza riferimenti non deallocato in un processo in esecuzione. Tuttavia, è davvero fino al sistema operativo come se una cosa del genere è considerato un "perdita di memoria".

La risposta è: dipende dal sistema operativo. Non riesco a pensare ad un moderno sistema operativo che non fa in questo modo. Ma i vecchi sistemi (credo fino a vincere 3.1 in Windows, e alcune vecchie piattaforme Linux embedded) se il programma ha chiuso senza rilasciare la sua memoria richiede il sistema operativo sarebbe tenerli fino a quando non riavviato.

Le perdite di memoria sono considerati un problema perché un'applicazione di lunga esecuzione lentamente spurgo distanza memoria di sistema e può nel caso peggiore rendere l'intera macchina grazie inutilizzabile di memoria insufficiente. Nel tuo caso, i termina applicazione e tutta la memoria allocata per l'applicazione saranno restituite al sistema, in modo certo un problema.

La vera domanda è: "Does myclass allocare qualsiasi memoria stessa che deve essere / liberi cancellato?"

Se non lo fa - se l'unico ricordo che utilizza è che i membri interni - allora esiste interamente sulla pila. Una volta che lascia che la funzione (ma lo fa), la memoria sullo stack viene recuperata e riutilizzata. myclass è andato. Questo è solo il modo in cui il lavoro stack.

Se myclass fa allocare la memoria che ha bisogno di essere liberati in essa di dtor, allora siete ancora fortunati, come il dtor sarà chiamato come la pila è svolto durante il lancio. Il dtor sarà già stato chiamato prima che l'eccezione è dichiarato non gestita e terminare si chiama.

L'unico posto dove si avrà un problema è se MyClass ha un dtor, e il dtor tiri come eccezione di essa possiede. Il secondo lancio si verificano durante lo svolgimento pila dal primo tiro avrà chiamata l'terminare immedaitely senza più dtors chiamati.

  

Da OP,

     

Se un tiro non viene gestita, si chiama,   terminate (), che a sua volta chiamate   abort () e si blocca l'applicazione.   In questo momento, gli oggetti della pila   non sono Destoryed (Il distruttore è   Non invocato).

Questo è un comportamento definito implementazione.

  

$ 15.3 / 9- "Se nessun gestore matching è   trovato in un programma, la funzione   terminate () è chiamato; anche se non   la pila è svolto prima questa chiamata   per terminare () è   implementazione definita (15.5.1). "

Quindi, se questo constituisce una perdita di memoria o non è anche l'implementazione definita comportamento, immagino.

  

La mia comprensione è "Quando l'applicazione termina (o di interruzione o di uscita normale), libera tutta la memoria che è stato assegnato per l'applicazione". Così questo non può essere considerato come perdita di memoria.

     

Ho ragione?

La perdita di memoria è un tipo di errore di programmazione che è classificata po 'più basso sulla scala di errori di programmazione -. Rispetto al eccezione non identificata

IOW, se il programma non termina correttamente, si blocca note anche come, allora è troppo presto per parlare di perdite di memoria.

D'altra nota, maggior parte degli analizzatori di memoria con cui ho lavorato negli ultimi dieci anni non avrebbe scattare alcun allarme perdita di memoria nel caso - perché non attivano allarmi quando programma si blocca in silenzio. Bisogna primo a fare programma non crash, solo allora eseguire il debug le perdite di memoria.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top