Memoria dinamica in C++: new e delete spiegati

Perché chiedere memoria a runtime

Finora ogni variabile che hai creato viveva sullo stack: la sua dimensione è nota in fase di compilazione e viene distrutta automaticamente quando il suo scope termina. È veloce e sicuro, ma non gestisce il caso in cui non sai quanta memoria ti serve finché il programma non è in esecuzione: un buffer dimensionato in base all'input dell'utente, una struttura che deve sopravvivere alla funzione che l'ha creata o un grafo la cui forma non è nota in anticipo.

Per questi casi il C++ ti permette di allocare dall'heap (chiamato anche free store) con new, e di restituire la memoria con delete. L'espressione new riserva un blocco, esegue il costruttore e restituisce un puntatore a quel blocco, basandosi direttamente sui puntatori che hai visto nella pagina precedente.

#include <iostream>
using namespace std;

int main() {
    int* p = new int(42);   // riserva un int sull'heap, inizializzato a 42

    cout << "value: " << *p << "\n";   // dereferenzia per leggerlo
    cout << "address: " << p << "\n";

    delete p;               // restituisce la memoria
    return 0;
}

La variabile p in sé vive sullo stack: è solo un puntatore. L'int a cui punta vive sull'heap e resta vivo finché non fai delete, indipendentemente da quanti scope si aprono e si chiudono.

Stack e heap

Questa distinzione è l'intero motivo per cui esiste new, quindi vale la pena renderla concreta.

void demo() {
    int a = 10;            // sullo stack, sparisce quando demo() termina
    int* b = new int(10);  // 'b' sullo stack, l'int a cui punta sull'heap
}                          // 'a' distrutto; l'int sull'heap è un LEAK, non viene mai liberato

Le differenze principali:

• Stack: durata automatica, molto veloce, dimensione limitata (di solito pochi MB), liberato per te quando lo scope termina.
• Heap: durata manuale, leggermente più lento, grande, e liberato solo quando chiami delete.

Lo scambio è flessibilità contro responsabilità: la memoria sull'heap vive esattamente quanto vuoi tu, ma diventi tu quello che deve ricordarsi di liberarla.

Allocare array con new[]

Quando ti serve un blocco la cui lunghezza viene decisa a runtime, usa la forma per array new T[n]. Restituisce un puntatore al primo elemento, e lo liberi con il corrispondente delete[].

#include <iostream>
using namespace std;

int main() {
    int n;
    cout << "How many numbers? ";
    cin >> n;

    int* arr = new int[n];      // n non è una costante di compilazione, valido per new[]

    for (int i = 0; i < n; ++i) {
        arr[i] = i * i;
    }
    for (int i = 0; i < n; ++i) {
        cout << arr[i] << " ";
    }
    cout << "\n";

    delete[] arr;               // nota le parentesi quadre: delete[], non delete
    return 0;
}

La regola è rigida e facile da sbagliare: la memoria ottenuta con new si libera con delete, e quella ottenuta con new[] si libera con delete[]. Mescolarli, cioè fare delete arr su qualcosa allocato con new[], è comportamento indefinito, anche se sul tuo computer sembra funzionare.

I tre bug classici

La gestione manuale della memoria ha un piccolo insieme di errori che causano la maggior parte dei bug sull'heap. Impara a riconoscerli tutti e tre.

1. Memory leak: non chiami mai delete. Il blocco resta riservato per sempre. Innocuo una volta, fatale in un ciclo.

void leaky() {
    int* p = new int(5);
    // ... nessun delete ...
}   // p sparisce; l'int sull'heap ora è irraggiungibile E non liberato

2. Puntatore pendente: usi la memoria dopo averla liberata. Il puntatore contiene ancora il vecchio indirizzo, ma quella memoria non è più tua.

#include <iostream>
using namespace std;

int main() {
    int* p = new int(7);
    delete p;            // la memoria torna all'heap

    // *p = 9;           // comportamento indefinito, p è pendente, NON farlo

    p = nullptr;         // buona abitudine: impostalo a null così l'uso errato fallisce in modo evidente
    cout << "deleted safely\n";
    return 0;
}

3. Double free: fai delete due volte sullo stesso blocco. Questo corrompe la contabilità interna dell'heap e di solito provoca un crash.

int* p = new int(1);
delete p;
delete p;   // double free, comportamento indefinito, spesso un crash

Impostare un puntatore a nullptr dopo averlo eliminato disinnesca sia l'uso di un puntatore pendente sia il double free: dereferenziare nullptr provoca subito un crash (facile da individuare), e delete nullptr è esplicitamente un'operazione sicura che non fa nulla.

Un ciclo realistico alloca, usa, libera

Mettendo tutto insieme, ecco la forma corretta della gestione manuale: alloca, usa, libera esattamente una volta e non toccare più il puntatore dopo.

#include <iostream>
#include <string>
using namespace std;

struct User {
    string name;
    int score;
};

int main() {
    User* u = new User{"Ada", 90};   // riserva + inizializza sull'heap

    cout << u->name << " scored " << u->score << "\n";   // -> per accedere ai membri
    u->score += 10;
    cout << "now " << u->score << "\n";

    delete u;        // esegue il distruttore di User e poi libera la memoria
    u = nullptr;
    return 0;
}

Nota che per un tipo classe delete u fa due cose: prima esegue il distruttore dell'oggetto, poi rilascia la memoria grezza. Quest'ordine conta quando i tuoi oggetti possiedono a loro volta delle risorse.

Un'insidia sottile: se viene lanciata un'eccezione tra new e delete, il delete non viene mai eseguito e hai un leak. Avvolgere ogni allocazione in un try/catch per gestirlo è noioso e soggetto a errori, ed è esattamente il problema che risolve la prossima pagina.

Prossimo: Smart pointer

Hai visto il costo completo della gestione manuale della memoria: ogni new è una promessa di fare delete più tardi, e una sola liberazione mancata, doppia o anticipata è comportamento indefinito. Il C++ moderno non fa quasi mai questa promessa a mano. La prossima pagina introduce gli smart pointer, std::unique_ptr e std::shared_ptr, oggetti che possiedono un'allocazione sull'heap e chiamano delete per te automaticamente quando escono dallo scope, trasformando tutti e tre i bug classici in cose di cui si occupano il compilatore e RAII al posto tuo.