std::variant è stato introdotto in C++17 come un'alternativa di unione sicura per il tipo, progettata per sostituire le unioni in stile C, soggette ad errori e gestite manualmente. Enforce l'invariante che mantiene sempre esattamente uno dei suoi tipi alternativi specificati, fornendo sicurezza di tipo a tempo di compilazione e semantica di valore intuitiva. Questo design garantisce teoricamente che operazioni come std::visit o std::get abbiano sempre un tipo valido su cui operare.
Lo stato valueless_by_exception rappresenta una modalità di errore specifica in cui la variante non contiene valore a causa di un'eccezione verificatasi durante le operazioni di modifica del tipo. Questa situazione si verifica quando la variante deve distruggere la propria alternativa attuale per far spazio a una nuova, ma la successiva costruzione della nuova alternativa solleva un'eccezione. Di conseguenza, l'oggetto resta senza un membro attivo valido, infrangendo temporaneamente l'invariante standard della variante.
La soluzione fornita dallo standard è di consentire questo singolo stato invalido specificamente per mantenere le garanzie di sicurezza di base delle eccezioni. Anche in questo stato, la variante rimane distruttibile e assegnabile, consentendo di ripulire le risorse e inserire nuovi valori nello spazio di archiviazione. Per riprendersi completamente da questa condizione, è necessario assegnare o emplace un nuovo valore, che ripristina l'invariante stabilendo un'alternativa valida e resettando lo stato interno di tracciamento.
std::variant<std::string, int> v = "hello"; try { v.emplace<std::string>(10000000, 'x'); // potrebbe sollevare bad_alloc } catch (...) { assert(v.valueless_by_exception()); v = 42; // Ripristino: valido di nuovo }
Considera un sistema di trading ad alta frequenza che elabora messaggi di dati di mercato rappresentati come std::variant<PriceUpdate, OrderCancel, TradeExecution>. Durante uno scenario di memoria limitata, un tentativo di assegnare un grande oggetto TradeExecution solleva std::bad_alloc dopo che la variante ha già distrutto il precedente PriceUpdate per fare spazio. Questa sequenza porta a una variante senza valore che si propaga attraverso il pipeline, potenzialmente causando guasti a catena se il codice downstream presume che siano presenti dati validi.
Una soluzione ha comportato l'imballaggio di ogni accesso alla variante con controlli di valueless_by_exception() e logica di recupero manuale prima di qualsiasi operazione di visita o recupero. Questo approccio ha fornito sicurezza esplicita contro comportamenti indefiniti, ma ha ingombro il codice con controlli difensivi in ogni punto di utilizzo, degradando significativamente la leggibilità e introducendo una latenza inaccettabile nel percorso critico di trading.
Un altro approccio ha considerato l'uso di std::optional<std::variant<...>> per esternalizzare lo stato vuoto al di fuori della variante stessa. Sebbene questo preservasse l'invariante interno della variante assicurando che la variante interna contenesse sempre un tipo valido, ha introdotto un secondo livello di indirezione e richiedeva un doppio dereferencing per ogni accesso, complicando la superficie API e potenzialmente impattando la località della cache durante l'elaborazione ad alta velocità.
Il team ha infine selezionato std::monostate come prima alternativa nella lista dei tipi della variante, riservando effettivamente uno stato "vuoto" esplicito all'interno del sistema di tipi normale della variante. Questa scelta ha eliminato la possibilità dello stato senza valore in quanto la variante poteva sempre tornare a contenere std::monostate invece di diventare senza valore, garantendo che index() restituisse sempre una posizione valida e che std::visit dispatchasse sempre con successo a dati reali o al gestore dello stato vuoto.
Il risultato è stato un robusto processore di messaggi che gestiva i guasti di allocazione con eleganza passando all'alternativa monostate piuttosto che a uno stato invalido eccezionale. Questo design ha mantenuto una rigorosa sicurezza di tipo senza richiedere controlli a tempo di esecuzione per la mancanza di valore o soffrire di un sovraccarico di doppia indirezione. Gli sviluppatori potevano fare affidamento sul fatto che la variante fosse sempre visitabile, con il gestore monostate che agiva come un no-op o comportamento predefinito per i messaggi vuoti.
Perché std::variant consente lo stato valueless_by_exception nonostante violi il principio generale di design secondo cui una variante dovrebbe sempre contenere uno dei suoi tipi specificati?
Lo standard privilegia la forte sicurezza delle eccezioni rispetto al mantenimento dell'invariante rigoroso a tutti i costi. Quando si cambia l'alternativa tenuta, la variante deve distruggere il vecchio valore prima di costruire il nuovo per prevenire perdite di risorse o problemi di doppia proprietà. Se questa nuova costruzione solleva, la variante non può tornare allo stato precedente poiché quello spazio è già distrutto, né può completare la transizione nel nuovo stato. Lo stato valueless_by_exception funge da necessaria via di fuga che indica che l'oggetto è distruttibile e assegnabile ma non contiene un'alternativa valida, prevenendo comportamenti indefiniti che deriverebbero dal fingere che il vecchio valore esista ancora o dal lasciare lo spazio di archiviazione non inizializzato.
Come si comporta std::visit quando invocato su una variante che è entrata nello stato valueless_by_exception, e perché ciò differisce dall'accesso a una variante che contiene std::monostate?
std::visit solleva immediatamente std::bad_variant_access quando incontra una variante senza valore perché l'indice del tipo attivo è variant_npos, che non si mappa a nessun sovraccarico di visitatore. Questo differisce fondamentalmente da std::monostate, che è un tipo legittimo anche se vuoto, occupando una posizione indice specifica all'interno della lista dei tipi della variante. Un visitatore può fornire un sovraccarico specifico per std::monostate per gestire gli stati vuoti in modo elegante come parte del normale flusso di controllo. Lo stato senza valore rappresenta una reale condizione di errore in cui le informazioni di tipo sono completamente perse, mentre monostate rappresenta uno stato vuoto valido e intenzionale all'interno del sistema di tipi che partecipa al meccanismo di dispatch della visita.
Può una variante recuperare dallo stato valueless_by_exception senza distruggere e ricostruire l'oggetto variante stesso, e quali operazioni specifiche facilitano questo recupero?
Sì, il recupero è possibile tramite operazioni di assegnazione o emplace senza la necessità di distruggere il wrapper della variante stessa. Quando esegui v = T{} o v.emplace<T>(args), e la costruzione del tipo T ha successo, la variante esce dallo stato senza valore e contiene il nuovo tipo. Questo funziona perché queste operazioni sono definite per stabilire una nuova alternativa attiva, re-inizializzando efficacemente lo spazio di archiviazione con un valore valido e resettando l'indice interno da variant_npos alla posizione di T. Leggere semplicemente dalla variante o chiamare osservatori non modificanti non cambierà lo stato; solo una operazione riuscita che inserisce un nuovo valore nello spazio di archiviazione può ripristinare l'invariante della classe e resettare il flag senza valore a falso.