La necessità deriva dalle regole di decadimento dei tipi in C++ e dalla necessità di selezione del deleter a tempo di compilazione. Quando un tipo array viene passato a un template, esso decada in un puntatore, rimuovendo le informazioni sull'estensione dell'array che distingue la deallocazione scalare (delete) da quella dell'array (delete[]). std::unique_ptr risolve questo attraverso la specializzazione parziale del template: il template primario std::unique_ptr<T> utilizza std::default_delete<T> che invoca delete scalare, mentre std::unique_ptr<T[]> instanzia std::default_delete<T[]> che invoca delete[]. Questa sintassi esplicita assicura che il compilatore generi il corretto codice di distruzione senza introspezione del tipo a tempo di esecuzione o sovraccarico.
Contesto: Un motore di elaborazione audio a bassa latenza riceve buffer di campioni PCM da un'API di driver hardware che restituisce float* allocati tramite new float[buffer_size]. Questi buffer devono passare attraverso una catena di filtri di elaborazione del segnale digitale mantenendo severi vincoli in tempo reale e sicurezza delle eccezioni.
Problema: Il team necessitava di una soluzione di puntatore intelligente che fornisse sicurezza RAII per questi array in stile C senza introdurre il sovraccarico di tracciamento delle dimensioni/capacità di std::vector, cosa che avrebbe violato i requisiti di allineamento delle cache-line per le operazioni SIMD. In particolare, utilizzare delete scalare su memoria allocata dell'array avrebbe corrotto l'heap e fatto crashare il pipeline audio.
Puntatore raw con eliminazione manuale. Questo approccio ha utilizzato puntatori nudi float* con chiamate esplicite a delete[] in ogni percorso di uscita. Pro: Zero sovraccarico di astrazione e compatibilità diretta con l'API hardware. Contro: Non sicuro per le eccezioni; se un filtro lanciasse un'eccezione durante l'elaborazione, il buffer sarebbe trapelato, e mantenere una logica di eliminazione corretta attraverso venti diversi stadi di filtro diventava insostenibile. Scartato a causa dei rischi di affidabilità in produzione.
Contenitore std::vector<float>. Avvolgere i buffer in std::vector ha fornito gestione automatica della memoria e tracciamento delle dimensioni. Pro: Sicurezza delle eccezioni e disponibilità di controllo dei limiti. Contro: std::vector memorizza implicitamente puntatori di capacità (tipicamente 24 byte di sovraccarico), che hanno infranto i contratti di allineamento DMA a dimensione fissa con l'hardware audio. Inoltre, std::vector presume proprietà mutabile e potenziale riallocazione, in conflitto con il pool di buffer fisso del driver.
Specializzazione std::unique_ptr<float[]>. Questa soluzione ha impiegato std::unique_ptr<float[]> che istanzia automaticamente std::default_delete<float[]>. Pro: Nessun sovraccarico (sizeof è uguale a un puntatore), invocazione garantita di delete[], semantica di spostamento per sostituzioni efficienti nella catena dei filtri e prevenzione della copia a tempo di compilazione. Contro: Perde informazioni sulle dimensioni a runtime richiedendo un tracciamento parallelo, e std::make_unique<float[]>(size) inizializza i valori degli elementi che potrebbero non essere necessari per i tipi POD.
Decisione e risultato. Abbiamo selezionato std::unique_ptr<float[]> combinato con una vista leggera simile a uno span per il tracciamento delle dimensioni. Questo ha fornito sicurezza delle eccezioni senza violare i vincoli di allineamento hardware. Il sistema ha elaborato flussi audio per mesi senza perdite di memoria, e la specializzazione esplicita dell'array ha catturato un bug critico durante la compilazione dove un sviluppatore tentava di usare std::unique_ptr<float> con un array-allocazione, forzando la sintassi corretta prima dell'esecuzione.
**Perché std::unique_ptr<Base[]> rifiuta l'inizializzazione da new Derived[N] quando std::unique_ptr<Derived> si converte in std::unique_ptr<Base>?
I tipi array presentano un comportamento non covariante a differenza dei puntatori singoli. Mentre Derived* si converte implicitamente in Base* tramite aggiustamento del puntatore, Derived[] non può convertirsi in Base[] perché l'aritmetica di indicizzazione dell'array dipende dalla dimensione del tipo statico; accedere all'elemento i in una vista Base[] di Derived[] calcolerebbe offset in byte errati. Pertanto, la specializzazione dell'array di std::unique_ptr elimina esplicitamente i costruttori di conversione tra diversi tipi di array per prevenire l'accesso alla memoria non allineata, mentre la versione scalare consente la conversione (richiedendo distruttori virtuali per la sicurezza).
Come inizializza std::make_unique<T[]>(n) gli elementi rispetto a std::make_unique<T>(args...), e perché questo limita la sua applicabilità?
L'overload dell'array std::make_unique<T[]>(n) esegue l'inizializzazione per valore su tutti gli n elementi, che inizializza a zero gli scalari o costruisce per default gli oggetti. Questo differisce dalla forma scalare che inoltra gli argomenti al costruttore di T. Questa distinzione impedisce l'uso di std::make_unique per array di tipi non costruibili per default, poiché non è possibile passare argomenti del costruttore per singoli elementi. I candidati spesso tentano std::make_unique<NonDefaultConstructible[]>(5, args), il che genera un errore di compilazione, costringendo a utilizzare loop manuali o std::vector con emplacement.
Quale comportamento indefinito si manifesta quando std::unique_ptr<T> (scalare) gestisce la memoria di new T[N], e perché i compilatori rimangono silenziosi?
Il std::unique_ptr scalare utilizza std::default_delete<T>, che chiama delete (delete scalare). Quando applicato alla memoria allocata dell'array da new T[N], questo costituisce un'incongruenza che risulta in un comportamento indefinito—tipicamente liberando solo la memoria del primo elemento o corrompendo i metadati dell'allocatore dell'heap. I compilatori non avvisano perché il parametro template T decade; new T[N] restituisce T*, e il sistema dei tipi perde la distinzione dell'array al momento della costruzione di std::unique_ptr. Questo modo di fallimento silenzioso è precisamente il motivo per cui std::unique_ptr<T[]> esiste come un'alternativa sicura per i tipi distinti.