È buona norma NULL un puntatore dopo averlo eliminato?

Inizierò dicendo: usa i puntatori intelligenti e non dovrai mai preoccuparti di questo.

Quali sono i problemi con il seguente codice?

Foo * p = new Foo;
// (use p)
delete p;
p = NULL;

Ciò è stato innescato da una risposta e commenti a un'altra domanda. Un commento di Neil Butterworth ha generato alcuni voti:

L'impostazione dei puntatori su NULL dopo l'eliminazione non è una buona pratica universale in C ++. Ci sono momenti in cui è una buona cosa da fare e momenti in cui è inutile e può nascondere errori.

Ci sono molte circostanze in cui non sarebbe d'aiuto. Ma nella mia esperienza, non può far male. Qualcuno mi illumina.

Impostando un puntatore su 0 (che è "null" in C ++ standard, il valore NULL definito da C è leggermente diverso) si evitano arresti anomali su doppie eliminazioni.

Considera quanto segue:

Foo* foo = 0; // Sets the pointer to 0 (C++ NULL)
delete foo; // Won't do anything

Mentre:

Foo* foo = new Foo();
delete foo; // Deletes the object
delete foo; // Undefined behavior 

In altre parole, se non si impostano i puntatori eliminati su 0, si avranno problemi se si eseguono doppie eliminazioni. Un argomento contro l'impostazione dei puntatori su 0 dopo l'eliminazione sarebbe che così facendo maschera solo i double bugs e li lascia non gestiti.

È meglio non avere doppi bug di eliminazione, ovviamente, ma a seconda della semantica della proprietà e dei cicli di vita degli oggetti, questo può essere difficile da ottenere in pratica. Preferisco un bug di doppia eliminazione mascherato rispetto a UB.

Infine, un sidoto sulla gestione dell'allocazione degli oggetti, ti suggerisco di dare un'occhiata alla std::unique_ptrproprietà rigorosa / singolare, std::shared_ptralla proprietà condivisa o ad un'altra implementazione del puntatore intelligente, a seconda delle tue esigenze.

Impostare i puntatori su NULL dopo aver eliminato ciò che indicava di certo non può far male, ma spesso è un po 'un cerotto su un problema più fondamentale: perché stai usando un puntatore in primo luogo? Posso vedere due motivi tipici:

• Volevi semplicemente qualcosa assegnato all'heap. Nel qual caso avvolgerlo in un oggetto RAII sarebbe stato molto più sicuro e pulito. Terminare l'ambito dell'oggetto RAII quando non è più necessario l'oggetto. Ecco come std::vectorfunziona e risolve il problema di lasciare accidentalmente i puntatori nella memoria allocata. Non ci sono puntatori.
• O forse volevi qualche semantica di proprietà condivisa complessa. Il puntatore restituito newpotrebbe non essere lo stesso di quello su cui deleteè stato chiamato. Nel frattempo più oggetti potrebbero aver usato l'oggetto contemporaneamente. In tal caso, sarebbe stato preferibile un puntatore condiviso o qualcosa di simile.

La mia regola empirica è che se si lasciano dei puntatori nel codice utente, lo si sta facendo in modo sbagliato. Il puntatore non dovrebbe essere lì per indicare la spazzatura in primo luogo. Perché un oggetto non si assume la responsabilità di garantirne la validità? Perché il suo ambito non termina quando l'oggetto puntato fa?

Ho una migliore pratica ancora migliore: ove possibile, termina l'ambito della variabile!

{
    Foo* pFoo = new Foo;
    // use pFoo
    delete pFoo;
}

Ho sempre impostato un puntatore su NULL(ora nullptr) dopo aver eliminato gli oggetti a cui punta.

1. Può aiutare a catturare molti riferimenti alla memoria liberata (supponendo che i guasti della tua piattaforma su un deref di un puntatore nullo).

2. Non catturerà tutti i riferimenti alla memoria libera se, ad esempio, ci sono copie del puntatore in giro. Ma alcuni è meglio di nessuno.

3. Maschera una doppia eliminazione, ma trovo che siano molto meno comuni degli accessi alla memoria già liberata.

4. In molti casi il compilatore lo ottimizzerà via. Quindi l'argomento che non è necessario non mi convince.

5. Se stai già usando RAII, allora non ci sono molti deletes nel tuo codice per cominciare, quindi l'argomento che l'assegnazione extra causa disordine non mi convince.

6. Spesso è conveniente, durante il debug, vedere il valore null piuttosto che un puntatore stantio.

7. Se questo ti dà ancora fastidio, usa invece un puntatore intelligente o un riferimento.

Ho anche impostato altri tipi di handle di risorse sul valore senza risorse quando la risorsa è libera (che di solito è solo nel distruttore di un wrapper RAII scritto per incapsulare la risorsa).

Ho lavorato su un grande prodotto commerciale (9 milioni di dichiarazioni) (principalmente in C). A un certo punto, abbiamo usato la magia macro per annullare il puntatore quando la memoria è stata liberata. Ciò ha immediatamente rivelato molti bug in agguato che sono stati prontamente risolti. Per quanto posso ricordare, non abbiamo mai avuto un bug double-free.

Aggiornamento: Microsoft ritiene che sia una buona pratica per la sicurezza e raccomanda tale pratica nei propri criteri SDL. Apparentemente MSVC ++ 11 calpesterà automaticamente il puntatore eliminato (in molte circostanze) se si compila con l'opzione / SDL.

In primo luogo, ci sono molte domande esistenti su questo e argomenti strettamente correlati, ad esempio Perché l'eliminazione non imposta il puntatore su NULL? .

Nel tuo codice, il problema è quello che succede (usa p). Ad esempio, se da qualche parte hai un codice come questo:

Foo * p2 = p;

quindi impostare p su NULL compie pochissimo, dato che hai ancora il puntatore p2 di cui preoccuparti.

Questo non significa che l'impostazione di un puntatore su NULL sia sempre inutile. Ad esempio, se p fosse una variabile membro che punta a una risorsa la cui durata non era esattamente la stessa della classe che contiene p, l'impostazione di p su NULL potrebbe essere un modo utile per indicare la presenza o l'assenza della risorsa.

Se c'è più codice dopo il delete , Sì. Quando il puntatore viene eliminato in un costruttore o alla fine del metodo o della funzione, No.

Il punto di questa parabola è ricordare al programmatore, durante il runtime, che l'oggetto è già stato cancellato.

Una pratica ancora migliore consiste nell'utilizzare i puntatori intelligenti (condivisi o con ambito) che eliminano automagicamente i loro oggetti di destinazione.

Come altri hanno già detto, delete ptr; ptr = 0;non farà in modo che i demoni volino fuori dal tuo naso. Tuttavia, incoraggia l'uso di ptrcome una sorta di bandiera. Il codice diventa disseminato deletee impostando il puntatore su NULL. Il prossimo passo è spargere il if (arg == NULL) return;tuo codice per proteggerti dall'uso accidentale di un NULLpuntatore. Il problema si verifica quando i controlli NULLdiventano il mezzo principale per verificare lo stato di un oggetto o programma.

Sono sicuro che c'è un odore di codice sull'uso di un puntatore come bandiera da qualche parte, ma non ne ho trovato uno.

Cambierò leggermente la tua domanda:

Utilizzeresti un puntatore non inizializzato? Sai, uno che non hai impostato su NULL o allocare la memoria a cui punta?

Esistono due scenari in cui è possibile saltare l'impostazione del puntatore su NULL:

• la variabile puntatore esce immediatamente dall'ambito
• hai sovraccaricato la semantica del puntatore e stai usando il suo valore non solo come puntatore di memoria, ma anche come chiave o valore grezzo. questo approccio tuttavia soffre di altri problemi.

Nel frattempo, sostenere che l'impostazione del puntatore su NULL potrebbe nascondermi degli errori sembra come sostenere che non si dovrebbe correggere un bug perché la correzione potrebbe nascondere un altro bug. Gli unici bug che potrebbero mostrare se il puntatore non è impostato su NULL sarebbero quelli che tentano di usare il puntatore. Ma impostarlo su NULL causerebbe esattamente lo stesso bug che mostrerebbe se lo si utilizza con memoria libera, no?

Se non hai altri vincoli che ti obbligano a impostare o non impostare il puntatore su NULL dopo averlo eliminato (uno di questi vincoli è stato citato da Neil Butterworth ), la mia preferenza personale è di lasciarlo.

Per me la domanda non è "è una buona idea?" ma "quale comportamento dovrei prevenire o consentire di fare questo?" Ad esempio, se ciò consente ad altro codice di vedere che il puntatore non è più disponibile, perché un altro codice sta anche tentando di guardare i puntatori liberati dopo che sono stati liberati? Di solito, è un bug.

Fa anche più lavoro del necessario e ostacola il debug post mortem. Meno tocchi la memoria dopo che non ti serve, più è facile capire perché qualcosa si è bloccato. Molte volte ho fatto affidamento sul fatto che la memoria è in uno stato simile a quando si è verificato un determinato bug per diagnosticare e correggere detto bug.

L'annullamento esplicito dopo l'eliminazione suggerisce fortemente a un lettore che il puntatore rappresenta qualcosa che è concettualmente facoltativo . Se lo vedessi, comincerei a preoccuparmi che ovunque nella fonte venga usato il puntatore, che dovrebbe essere prima testato contro NULL.

Se questo è ciò che realmente intendi, è meglio renderlo esplicito nella fonte usando qualcosa come boost :: opzionale

optional<Foo*> p (new Foo);
// (use p.get(), but must test p for truth first!...)
delete p.get();
p = optional<Foo*>();

Ma se davvero volevi che la gente sapesse che il puntatore è "andato male", presenterò un accordo al 100% con coloro che affermano che la cosa migliore da fare è renderlo fuori portata. Quindi stai usando il compilatore per prevenire la possibilità di cattive dereferenze in fase di esecuzione.

Questo è il bambino in tutta l'acqua del bagno C ++, non dovrebbe buttarlo via. :)

In un programma ben strutturato con controllo degli errori appropriato, non vi è alcun motivo per non assegnarlo null. 0si distingue come un valore non valido universalmente riconosciuto in questo contesto. Fallire duramente e fallire presto.

Molti degli argomenti contro l'assegnazione 0suggeriscono che potrebbe nascondere un bug o complicare il flusso di controllo. Fondamentalmente, questo è o un errore a monte (non colpa tua (scusate il cattivo gioco di parole)) o un altro errore per conto del programmatore - forse anche un'indicazione che il flusso del programma è diventato troppo complesso.

Se il programmatore vuole introdurre l'uso di un puntatore che può essere nullo come valore speciale e scrivere tutto il necessario schivando attorno a ciò, questa è una complicazione che hanno deliberatamente introdotto. Migliore è la quarantena, prima si trovano casi di uso improprio e meno sono in grado di diffondersi in altri programmi.

Programmi ben strutturati possono essere progettati usando le funzionalità C ++ per evitare questi casi. Puoi usare i riferimenti, oppure puoi semplicemente dire "passare / utilizzare argomenti nulli o non validi è un errore" - un approccio che è ugualmente applicabile ai contenitori, come i puntatori intelligenti. L'aumento del comportamento coerente e corretto impedisce a questi bug di andare lontano.

Da lì, hai solo un ambito e un contesto molto limitati in cui può esistere (o è consentito) un puntatore nullo.

Lo stesso può essere applicato ai puntatori che non lo sono const. Seguire il valore di un puntatore è banale perché il suo ambito è così piccolo e l'uso improprio è controllato e ben definito. Se il tuo set di strumenti e i tuoi ingegneri non riescono a seguire il programma dopo una lettura veloce o c'è un controllo degli errori inappropriato o un flusso di programma incoerente / indulgente, hai altri, maggiori problemi.

Infine, il tuo compilatore e l'ambiente probabilmente hanno delle protezioni per i momenti in cui desideri introdurre errori (scarabocchiare), rilevare accessi alla memoria liberata e catturare altri UB correlati. Puoi anche introdurre una diagnostica simile nei tuoi programmi, spesso senza influire sui programmi esistenti.

Lasciami espandere ciò che hai già inserito nella tua domanda.

Ecco cosa hai inserito nella tua domanda, in forma di punto elenco:

L'impostazione dei puntatori su NULL dopo l'eliminazione non è una buona pratica universale in C ++. Ci sono momenti in cui:

• è una buona cosa da fare
• e volte in cui è inutile e può nascondere errori.

Tuttavia, non ci sono momenti in cui questo è male ! Si Non introdurre più bug da annullamento dei esplicitamente, non sarà perdite di memoria, non sarà causa comportamento non definito per accadere.

Quindi, in caso di dubbio, basta annullarlo.

Detto questo, se ritieni di dover annullare esplicitamente qualche puntatore, allora per me sembra che tu non abbia diviso abbastanza un metodo, e dovresti guardare l'approccio di refactoring chiamato "Metodo di estrazione" per suddividere il metodo in parti separate.

Sì.

L'unico "danno" che può fare è introdurre inefficienza (un'operazione di archiviazione non necessaria) nel programma - ma questo sovraccarico sarà insignificante rispetto al costo di allocazione e liberazione del blocco di memoria nella maggior parte dei casi.

Se non lo fai, ti sarà avere alcune brutte puntatore bug derefernce un giorno.

Uso sempre una macro per eliminare:

#define SAFEDELETE(ptr) { delete(ptr); ptr = NULL; }

(e simili per un array, free (), rilasci di handle)

È inoltre possibile scrivere metodi di "eliminazione automatica" che prendono un riferimento al puntatore del codice chiamante, in modo da forzare il puntatore del codice chiamante su NULL. Ad esempio, per eliminare una sottostruttura di molti oggetti:

static void TreeItem::DeleteSubtree(TreeItem *&rootObject)
{
    if (rootObject == NULL)
        return;

    rootObject->UnlinkFromParent();

    for (int i = 0; i < numChildren)
       DeleteSubtree(rootObject->child[i]);

    delete rootObject;
    rootObject = NULL;
}

modificare

Sì, queste tecniche violano alcune regole sull'uso delle macro (e sì, in questi giorni probabilmente potresti ottenere lo stesso risultato con i modelli) - ma usando molti anni non ho mai avuto accesso alla memoria morta - uno dei più cattivi e difficili e la maggior parte del tempo necessario per il debug dei problemi che si possono affrontare. In pratica per molti anni hanno eliminato efficacemente una intera classe di bug da ogni squadra su cui li ho introdotti.

Esistono anche molti modi per implementare quanto sopra: sto solo cercando di illustrare l'idea di forzare le persone a NULL un puntatore se eliminano un oggetto, piuttosto che fornire loro un mezzo per liberare la memoria che non NULL il puntatore del chiamante .

Naturalmente, l'esempio sopra è solo un passo verso un puntatore automatico. Il che non ho suggerito perché l'OP stava specificatamente chiedendo il caso di non usare un puntatore automatico.

"Ci sono volte in cui è una buona cosa da fare e volte in cui è inutile e può nascondere errori"

Riesco a vedere due problemi: quel semplice codice:

delete myObj;
myobj = 0

diventa un for-liner in ambiente multithread:

lock(myObjMutex); 
delete myObj;
myobj = 0
unlock(myObjMutex);

La "migliore pratica" di Don Neufeld non si applica sempre. Ad esempio, in un progetto automobilistico abbiamo dovuto impostare i puntatori su 0 anche nei distruttori. Posso immaginare che in software critici per la sicurezza tali regole non siano rare. È più facile (e saggio) seguirli che cercare di persuadere il team / checker del codice per ogni utilizzo del puntatore nel codice, che una riga che annulla questo puntatore è ridondante.

Un altro pericolo è fare affidamento su questa tecnica nel codice che utilizza eccezioni:

try{  
   delete myObj; //exception in destructor
   myObj=0
}
catch
{
   //myObj=0; <- possibly resource-leak
}

if (myObj)
  // use myObj <--undefined behaviour

In tale codice o si produce una perdita di risorse e si rimanda il problema o il processo si arresta in modo anomalo.

Quindi, questi due problemi che mi passano spontaneamente in testa (Herb Sutter direbbe sicuramente di più) mi fanno tutte le domande del tipo "Come evitare di usare i puntatori intelligenti e fare il lavoro in sicurezza con i normali puntatori" come obsoleti.

Ci sono sempre puntatori ciondolanti di cui preoccuparsi.

Se devi riallocare il puntatore prima di riutilizzarlo (dereferenziandolo, passandolo a una funzione, ecc.), Rendere il puntatore NULL è solo un'operazione aggiuntiva. Tuttavia, se non si è sicuri che verrà riallocato o meno prima che venga riutilizzato, impostarlo su NULL è una buona idea.

Come molti hanno già detto, è ovviamente molto più semplice utilizzare solo i puntatori intelligenti.

Modifica: come ha detto Thomas Matthews in questa precedente risposta , se un puntatore viene eliminato in un distruttore, non è necessario assegnargli NULL poiché non verrà riutilizzato perché l'oggetto è già stato distrutto.

Posso immaginare di impostare un puntatore su NULL dopo averlo eliminato, utile in rari casi in cui esiste uno scenario legittimo di riutilizzo in una singola funzione (o oggetto). Altrimenti non ha senso - un puntatore deve indicare qualcosa di significativo finché esiste - punto.

Se il codice non appartiene alla parte più critica delle prestazioni della tua applicazione, mantienila semplice e usa shared_ptr:

shared_ptr<Foo> p(new Foo);
//No more need to call delete

Esegue il conteggio dei riferimenti ed è thread-safe. Puoi trovarlo nel tr1 (std :: tr1 namespace, #include <memory>) o se il tuo compilatore non lo fornisce, prendilo da boost.