Storia: In C++98, la gestione delle risorse seguiva la Regola del Tre: se una classe necessitava di un distruttore personalizzato, costruttore di copia o operatore di assegnazione per copia, probabilmente necessitava di tutti e tre. Quando C++11 ha introdotto la semantica di spostamento, questa è diventata la Regola del Cinque, aggiungendo il costruttore di spostamento e l'operatore di assegnazione per spostamento. Il comitato standard ha scelto un approccio conservativo: dichiarare qualsiasi distruttore (anche quelli triviali) inibisce la generazione implicita delle operazioni di spostamento per prevenire spostamenti superficiali accidentali delle risorse gestite dai distruttori.
Problema: Quando scrivi ~MyClass() = default; all'interno della definizione della classe, crei un distruttore "dichiarato dall'utente". Per lo standard C++ ([class.copy.ctor]/3), questa presenza sopprime la dichiarazione implicita sia del costruttore di spostamento sia dell'operatore di assegnazione per spostamento. Di conseguenza, il compilatore tratta la classe come solo per copia, tornando silenziosamente a semantiche di copia costose durante le riallocazioni di std::vector o durante le ottimizzazioni di ritorno per valore, anche se il distruttore non esegue alcun lavoro effettivo.
Soluzione: Per mantenere la generazione implicita dello spostamento, dichiara il distruttore solo all'interno della classe e forniscine la definizione predefinita all'esterno:
class Optimized { public: ~Optimized(); // Solo dichiarato qui std::array<char, 4096> buffer; }; Optimized::~Optimized() = default; // Definito all'esterno
Questo rende il distruttore "fornito dall'utente" ma non "dichiarato dall'utente" nel punto in cui il compilatore decide di generare gli spostamenti. In alternativa, puoi dichiarare esplicitamente tutti e cinque i membri speciali predefiniti, o preferibilmente seguire la Regola dello Zero sostituendo le risorse raw con std::unique_ptr o contenitori.
Ci siamo imbattuti in questo in un motore di trading ad alta frequenza che elaborava oggetti MarketDataPacket. La classe conteneva un buffer fisso di 4KB per i dati di rete:
class MarketDataPacket { public: ~MarketDataPacket() = default; // Scritto nell'intestazione per "chiarezza" char buffer[4096]; };
Dopo la migrazione a C++11, il profiling della latenza ha rivelato che il 40% dei cicli della CPU veniva speso in memcpy nonostante la restituzione dei pacchetti per valore. Il colpevole era il distruttore predefinito dichiarato nella classe, che inavvertitamente ha eliminato gli spostamenti impliciti e costretto le copie durante la crescita di std::vector e i ritorni di funzione.
Soluzione 1: Dichiarare esplicitamente un costruttore di spostamento e un operatore di assegnazione noexcept. Questo risolve immediatamente il problema delle prestazioni attivando gli spostamenti. Tuttavia, richiede di mantenere manualmente queste funzioni quando si aggiungono membri, rischia discrepanze nelle specifiche delle eccezioni se sono coinvolti puntatori raw e aggiunge codice ripetitivo che viola la Regola dello Zero.
Soluzione 2: Sposta la definizione del distruttore nel file .cpp con MarketDataPacket::~MarketDataPacket() = default;. Questo ripristina gli spostamenti generati dal compilatore mantenendo il distruttore trivial. Mantiene l'astrazione a costo zero e consente ottimizzazioni del compilatore come l'eliminazione delle chiamate al distruttore per oggetti non utilizzati. L'unico svantaggio è la necessità di un'unità di compilazione separata, che era accettabile.
Soluzione 3: Sostituisci il buffer raw con std::vector<uint8_t> o std::unique_ptrstd::byte[]. Questo raggiunge la conformità perfetta con la Regola dello Zero. Tuttavia, ciò introduce un'indirezione o un sovraccarico di allocazione della heap inaccettabile nei percorsi di trading sensibili ai microsecondi dove la località della cache è critica.
Abbiamo selezionato la Soluzione 2. Spostando il predefinito all'esterno della classe, abbiamo ripristinato gli spostamenti impliciti, ridotto la latenza di elaborazione dei pacchetti da 12μs a 3μs e mantenuto la distruttibilità trivialmente consentendo ottimizzazioni aggressive da parte del compilatore.
Perché il compilatore distingue tra dichiarazione predefinita all'interno e all'esterno della classe quando i significati sono identici?
La differenza è sintattica, non semantica. C++ utilizza un modello di parsing a passaggio singolo per le definizioni delle classi. Quando il compilatore raggiunge la parentesi graffa di chiusura della classe, deve decidere se generare operazioni di spostamento implicite. Se vede = default all'interno, il distruttore è "dichiarato dall'utente" in quel momento, attivando le regole di soppressione secondo [class.copy]/7. Il compilatore non può "guardare avanti" nella definizione esterna per modificare questa decisione. Questa è una limitazione fondamentale del modello di compilazione di C++.
Marcare il distruttore come noexcept ripristina gli spostamenti impliciti?
No. La soppressione della generazione di spostamenti impliciti dipende esclusivamente dal fatto che il distruttore sia dichiarato dall'utente, non dalla sua specificazione delle eccezioni. Anche se contrassegnare gli spostamenti come noexcept è cruciale affinché possano essere utilizzati nelle riallocazioni di std::vector, semplicemente aggiungere noexcept a un distruttore predefinito all'interno della classe non riporta le operazioni di spostamento eliminate. Devi spostare la definizione all'esterno o predefinire esplicitamente gli spostamenti.
ComeInfluenza un distruttore dichiarato dall'utente l'inizializzazione aggregata?
Una classe con qualsiasi distruttore dichiarato dall'utente smette di essere un aggregato. Questo è spesso più dirompente rispetto alla perdita degli spostamenti. Significa perdere inizializzatori designati (C++20) e la possibilità di utilizzare elenchi di inizializzazione racchiusi tra parentesi senza costruttori espliciti. Molti sviluppatori si aspettano che l'inizializzazione aggregata funzioni e sono sorpresi quando non funziona:
struct Config { ~Config() = default; // Rovina l'aggregazione int value; }; // Config c{42}; // Errore: nessun costruttore corrispondente
Questo accade perché la presenza di un distruttore dichiarato dall'utente costringe la classe ad avere semantiche di distruzione non triviale nel sistema di tipi, escludendola dalla categoria aggregata indipendentemente dalla reale complessità.