Un libro in C ++ che ho letto afferma che quando un puntatore viene eliminato utilizzando l' deleteoperatore, la memoria nella posizione a cui punta viene "liberata" e può essere sovrascritta. Indica inoltre che il puntatore continuerà a puntare nella stessa posizione fino a quando non viene riassegnato o impostato su NULL.

In Visual Studio 2012 tuttavia; questo non sembra essere il caso!

Esempio:

#include <iostream>

using namespace std;

int main()
{
    int* ptr = new int;
    cout << "ptr = " << ptr << endl;
    delete ptr;
    cout << "ptr = " << ptr << endl;

    system("pause");

    return 0;
}

Quando compilo ed eseguo questo programma ottengo il seguente output:

ptr = 0050BC10
ptr = 00008123
Press any key to continue....

Chiaramente l'indirizzo a cui punta il puntatore cambia quando viene chiamato delete!

Perché sta succedendo? Questo ha qualcosa a che fare con Visual Studio in particolare?

E se cancellare può cambiare l'indirizzo a cui punta comunque, perché eliminare non dovrebbe impostare automaticamente il puntatore NULLinvece di un indirizzo casuale?

Ho notato che l'indirizzo memorizzato ptrveniva sempre sovrascritto con 00008123...

Mi è sembrato strano, quindi ho fatto un po 'di ricerche e ho trovato questo post sul blog di Microsoft contenente una sezione che discute "Sanificazione automatizzata del puntatore durante l'eliminazione di oggetti C ++".

... i controlli per NULL sono un costrutto di codice comune, il che significa che un controllo esistente per NULL combinato con l'utilizzo di NULL come valore di sanificazione potrebbe nascondere casualmente un vero problema di sicurezza della memoria la cui causa principale necessita davvero di essere risolta.

Per questo motivo abbiamo scelto 0x8123 come valore di sanificazione: dal punto di vista del sistema operativo questo si trova nella stessa pagina di memoria dell'indirizzo zero (NULL), ma una violazione di accesso a 0x8123 si distinguerà meglio per lo sviluppatore che necessita di un'attenzione più dettagliata .

Non solo spiega cosa fa Visual Studio con il puntatore dopo che è stato eliminato, ma risponde anche perché hanno scelto di NON impostarlo NULLautomaticamente!

Questa "funzione" è abilitata come parte dell'impostazione "Controlli SDL". Per abilitarlo / disabilitarlo vai a: PROGETTO -> Proprietà -> Proprietà di configurazione -> C / C ++ -> Generale -> Controlli SDL

Per confermare questo:

La modifica di questa impostazione e la riesecuzione dello stesso codice producono il seguente output:

ptr = 007CBC10
ptr = 007CBC10

"feature" è racchiuso tra virgolette perché nel caso in cui si disponga di due puntatori nella stessa posizione, la chiamata a delete eliminerà solo UNO di essi. L'altro verrà lasciato puntando alla posizione non valida ...

AGGIORNARE:

Dopo altri 5 anni di esperienza nella programmazione C ++, mi rendo conto che l'intero problema è sostanzialmente un punto controverso. Se sei un programmatore C ++ e stai ancora utilizzando newe deletegestendo puntatori non elaborati anziché utilizzare puntatori intelligenti (che eludono l'intero problema), potresti prendere in considerazione un cambiamento nel percorso di carriera per diventare un programmatore C. ;)

Vedi gli effetti collaterali /sdldell'opzione di compilazione. Attivato per impostazione predefinita per i progetti VS2015, consente controlli di sicurezza aggiuntivi oltre a quelli forniti da / gs. Usa Progetto> Proprietà> C / C ++> Generale> Impostazioni dei controlli SDL per modificarlo.

Citando l' articolo di MSDN :

• Esegue una sanificazione limitata del puntatore. Nelle espressioni che non implicano dereferenze e nei tipi che non hanno un distruttore definito dall'utente, i riferimenti del puntatore vengono impostati su un indirizzo non valido dopo una chiamata da eliminare. Questo aiuta a prevenire il riutilizzo di riferimenti a puntatori non aggiornati.

Tieni presente che l'impostazione dei puntatori eliminati su NULL è una cattiva pratica quando si utilizza MSVC. Elimina l'aiuto che ricevi sia dall'heap di debug sia da questa opzione / sdl, non puoi più rilevare chiamate libere / cancellate non valide nel tuo programma.

Indica inoltre che il puntatore continuerà a puntare nella stessa posizione fino a quando non viene riassegnato o impostato su NULL.

Questa è sicuramente un'informazione fuorviante.

Chiaramente l'indirizzo a cui punta il puntatore cambia quando viene chiamato delete!

Perché sta succedendo? Questo ha qualcosa a che fare con Visual Studio in particolare?

Questo è chiaramente all'interno delle specifiche della lingua. ptrnon è valido dopo la chiamata a delete. L'uso ptrdopo che è stato deleted è causa di comportamento indefinito. Non farlo L'ambiente di runtime è libero di fare tutto ciò che vuole ptrdopo la chiamata a delete.

E se delete può cambiare l'indirizzo a cui punta comunque, perché non eliminare automaticamente impostare il puntatore su NULL invece di un indirizzo casuale ???

La modifica del valore del puntatore su qualsiasi valore precedente rientra nelle specifiche della lingua. Per quanto riguarda il cambio in NULL, direi, sarebbe male. Il programma si comporterebbe in modo più sano se il valore del puntatore fosse impostato su NULL. Tuttavia, ciò nasconderà il problema. Quando il programma viene compilato con impostazioni di ottimizzazione diverse o trasferito in un ambiente diverso, il problema verrà probabilmente visualizzato nel momento più inopportuno.

delete ptr;
cout << "ptr = " << ptr << endl;

In generale, anche la lettura (come si fa sopra, nota: questo è diverso dal dereferenziamento) dei valori di puntatori non validi (il puntatore diventa non valido ad esempio quando lo si deletefa) è un comportamento definito dall'implementazione. Questo è stato introdotto in CWG # 1438 . Vedi anche qui .

Si noti che prima di leggere i valori dei puntatori non validi era un comportamento indefinito, quindi ciò che si ha sopra sarebbe un comportamento indefinito, il che significa che potrebbe succedere di tutto.

Credo che tu stia eseguendo una sorta di modalità di debug e VS sta tentando di reimpostare il puntatore in una posizione nota, in modo che si possa rintracciare e riportare ulteriori tentativi di dereferenza. Prova a compilare / eseguire lo stesso programma in modalità di rilascio.

I puntatori di solito non vengono cambiati all'interno deleteper motivi di efficienza ed evitare di dare una falsa idea di sicurezza. L'impostazione del puntatore di eliminazione su un valore predefinito non funzionerà nella maggior parte degli scenari complessi, poiché è probabile che il puntatore che si sta eliminando sia solo uno dei tanti che puntano a questa posizione.

È un dato di fatto, più ci penso, più trovo che VS sia in colpa quando lo fa, come al solito. Cosa succede se il puntatore è const? Lo cambierà ancora?

Dopo aver eliminato il puntatore, la memoria a cui punta potrebbe essere ancora valida. Per manifestare questo errore, il valore del puntatore è impostato su un valore ovvio. Questo aiuta davvero il processo di debug. Se il valore fosse impostato su NULL, potrebbe non apparire mai come potenziale bug nel flusso del programma. Quindi potrebbe nascondere un bug quando si esegue il test in seguito contro NULL.

Un altro punto è che alcuni ottimizzatori del tempo di esecuzione possono controllare quel valore e modificarne i risultati.

In tempi precedenti MS ha impostato il valore su 0xcfffffff.