In che modo l'abbinamento nuovo [] con eliminazione può portare solo alla perdita di memoria?

Question

Prima di tutto, usare delete per qualsiasi cosa allocata con new[] è un comportamento non definito secondo lo standard C++.

In Visual C++ 7 tale abbinamento può portare a una delle due conseguenze.

Se il tipo di nuova [] 'ed ha costruttore banale e distruttore VC++ usa semplicemente new invece di new[] e l'utilizzo di delete per quel blocco funziona bene - new solo chiama 'allocare memoria', delete chiama semplicemente 'memoria libera'.

Se il tipo new [] 'ed ha un costruttore o distruttore non banale il trucco sopra non può essere fatto - VC++ 7 deve invocare esattamente il giusto numero di distruttori. Quindi prepara l'array con un size_t memorizzando il numero di elementi. Ora l'indirizzo restituito da new[] punti sul primo elemento, non all'inizio del blocco. Quindi, se viene utilizzato delete, chiama solo il distruttore per il primo elemento e le chiamate "memoria libera" con l'indirizzo diverso da quello restituito da "allocare memoria" e questo porta a qualche indicazione di errore all'interno di HeapFree() che a mio avviso si riferisce a corruzione dell'heap.

Eppure ogni qui e là si possono leggere dichiarazioni false che utilizzando delete dopo new[] porta a una perdita di memoria. Sospetto che qualsiasi dimensione della corruzione dell'heap sia molto più importante di un fatto che il distruttore è chiamato solo per il primo elemento e che probabilmente i distruttori non chiamati non hanno liberato oggetti secondari allocati all'heap.

In che modo l'utilizzo di delete dopo il new[] può portare solo a una perdita di memoria in alcune implementazioni C++?

Answer 1

Supponiamo che io sia un compilatore C++ e implemento la gestione della mia memoria in questo modo: antepone ogni blocco di memoria riservata alla dimensione della memoria, in byte. Qualcosa come questo;

| size | data ... | 
     ^
     pointer returned by new and new[] 

noti che, in termini di allocazione di memoria, non c'è differenza tra new e new[]: entrambi solo allocare un blocco di memoria di una certa dimensione.

Ora come sarà il delete[] a conoscere la dimensione della matrice, al fine di chiamare il numero giusto di distruttori? È sufficiente dividere lo size del blocco di memoria con sizeof(T), dove T è il tipo di elementi dell'array.

Supponiamo ora di implementare delete come una sola chiamata al distruttore, seguita dalla liberazione dei byte size, quindi i distruttori degli elementi successivi non verranno mai chiamati. Ciò si traduce in perdite di risorse allocate dagli elementi successivi. Tuttavia, poiché I do byte liberi size (non sizeof(T) byte), non si verifica alcun danneggiamento dell'heap.

Answer 2

Se il distruttore non banale che non è chiamato per tutti tranne il primo elemento nell'array dovrebbe liberare della memoria si ottiene una perdita di memoria poiché questi oggetti non vengono ripuliti correttamente.

Answer 3

Oltre al risultato di un comportamento non definito, la causa più semplice delle perdite si trova nell'implementazione che non chiama il distruttore per tutti tranne il primo oggetto nell'array. Ciò ovviamente causerà perdite se gli oggetti hanno risorse allocate.

Questa è la classe più semplice possibile che riuscivo a pensare con conseguente questo comportamento:

struct A { 
     char* ch; 
     A(): ch(new char){} 
     ~A(){ delete ch; } 
    }; 

A* as = new A[10]; // ten times the A::ch pointer is allocated 

delete as; // only one of the A::ch pointers is freed. 

PS: notare che i costruttori non riescono a ottenere chiamato in un sacco di altri errori di programmazione, anche: i distruttori della classe base non virtuali , falsa dipendenza da puntatori intelligenti, ...

Answer 4

Ciò causerà una perdita in TUTTE le implementazioni di C++ in tutti i casi in cui il distruttore libera la memoria, perché il distruttore non viene mai chiamato.

In alcuni casi può causare errori molto peggiori.

Answer 5

perdita di memoria potrebbe accadere se l'operatore new() viene sovrascritto ma nuovo [] non lo è. lo stesso vale per l'operatore delete/delete []

Answer 6

Sembra che la tua domanda sia davvero "perché la corruzione dell'heap non accade?". La risposta a questo è "perché il gestore dell'heap tiene traccia delle dimensioni dei blocchi allocate". Torniamo a C per un minuto: se vuoi assegnare un singolo int in C, devi fare int* p = malloc(sizeof(int)), se vuoi assegnare un array di dimensioni n puoi scrivere int* p = malloc(n*sizeof(int)) o int* p = calloc(n, sizeof(int)). Ma in ogni caso lo libererai per free(p), indipendentemente da come lo hai assegnato. Non si passa mai la dimensione a free(), free() solo "sa" quanto liberare, poiché la dimensione di un blocco malloc() - ed è salvata da qualche parte "davanti" al blocco. Tornando al C++, new/delete e new []/delete [] sono di solito implementati in termini di malloc (anche se non devono esserlo, non dovresti fare affidamento su questo). Questo è il motivo per cui la nuova combinazione []/delete non corrompe l'heap: l'eliminazione libera la giusta quantità di memoria, ma, come spiegato da tutti prima di me, è possibile ottenere perdite non chiamando il numero corretto di distruttori.

Detto questo, ragionare sul comportamento non definito in C++ è sempre un esercizio inutile. Perché è importante se la nuova combinazione []/delete funziona, "solo" perdite o causa il danneggiamento dell'heap? Non dovresti scrivere un codice del genere, punto! E, in pratica, eviterei la gestione manuale della memoria ogni volta che è possibile - l'aumento di STL & esiste per un motivo.

Answer 7

La fiaba del mixaggio di new[] e delete che presumibilmente causa una perdita di memoria è proprio questo: una favola. Non ha assolutamente alcun fondamento nella realtà. Non so da dove venisse, oramai ha acquisito una vita propria e sopravvive come un virus, propagandosi dal passaparola da un principiante all'altro.

La più probabile logica dietro questa dialogo "perdita di memoria" è che dal punto innocentemente ingenuo di vista della differenza tra delete e delete[] è che delete viene utilizzato per distruggere un solo oggetto, mentre delete[] distrugge un array di oggetti (" molti "oggetti"). Una conclusione ingenua che di solito deriva da questo è che il primo elemento dell'array verrà distrutto da delete, mentre il resto persisterà, creando così la presunta "perdita di memoria". Naturalmente, qualsiasi programmatore che abbia almeno una conoscenza di base delle tipiche implementazioni dell'heap comprenderebbe immediatamente che la conseguenza più probabile è la corruzione dell'heap, non una "perdita di memoria".

Un'altra spiegazione popolare per l'ingenua teoria della "perdita di memoria" è che, poiché viene chiamato il numero errato di distruttori, la memoria secondaria di proprietà degli oggetti nell'array non viene deallocata. Questo potrebbe essere vero, ma è ovviamente una spiegazione molto forzata, che ha poca rilevanza di fronte a un problema molto più serio con la corruzione dell'heap.

In breve, la miscelazione di diverse funzioni di allocazione è uno di quegli errori che portano a un comportamento non definito solido, imprevedibile e pratico . Qualsiasi tentativo di imporre dei limiti concreti alle manifestazioni di questo comportamento indefinito è solo una perdita di tempo e un segno sicuro della mancanza di comprensione di base.

Inutile aggiungere, new/delete e new[]/delete[] sono infatti due meccanismi indipendenti di gestione della memoria, che sono personalizzabili in modo indipendente. Una volta che vengono personalizzati (sostituendo le funzioni di gestione della memoria non elaborata) non c'è assolutamente modo di iniziare a prevedere cosa potrebbe accadere se si mischiano.

Answer 8

In ritardo per una risposta, ma ...

Se il meccanismo di eliminazione è semplicemente quello di chiamare il distruttore e posizionare il puntatore liberato, insieme con la dimensione implicita sizeof, su una pila libera, quindi chiamando cancella su un blocco di memoria allocato con nuovo [] per cui la memoria viene persa, ma non per corruzione. Le strutture malloc più sofisticate potrebbero corrompere o rilevare questo comportamento.

Answer 9

Perché la risposta non può essere che causa entrambi?

Ovviamente la memoria è trapelata se la corruzione dell'heap si verifica o meno.

O meglio, dal momento che posso ri-implementare nuovo e cancellare ..... non può non causare nulla. Tecnicamente posso causare nuovi e cancellare per eseguire nuovi [] ed eliminare [].

HENCE: comportamento non definito.

Answer 10

Stavo rispondendo a una domanda che è stata contrassegnata come duplicata, quindi la copierò qui solo nel caso in cui la metta in crisi. È stato detto molto prima di me il modo in cui funziona l'allocazione della memoria, spiegherò solo la causa degli effetti &.

Solo una piccola cosa giusta fuori google: http://en.cppreference.com/w/cpp/memory/new/operator_delete

In ogni caso, eliminare è una funzione per un singolo oggetto. Libera l'istanza dal puntatore e lascia;

delete [] è una funzione utilizzata per deallocare array. Ciò significa che non si limita a liberare il puntatore; Dichiara l'intero blocco di memoria di quell'array come spazzatura.

In pratica è tutto molto bello, ma mi dici che la tua applicazione funziona. Probabilmente ti starai chiedendo ... perché?

La soluzione è C++ non riuscite perdite di memoria. Se userai cancella senza parentesi, eliminerà solo la matrice come oggetto - un processo che potrebbe causare una perdita di memoria .

bella storia, perdita di memoria, perché dovrebbe importarmi?

La perdita di memoria si verifica quando la memoria allocata non viene eliminata. Quella memoria quindi richiede uno spazio disco non necessario, che ti farà perdere memoria utile praticamente senza motivo. Questa è una cattiva programmazione e probabilmente dovresti risolverla nei tuoi sistemi.