Quando si invoca std::map::emplace con argomenti come map.emplace(key, value_args...), lo standard C++ richiede che l'implementazione costruisca un temporaneo std::pair<const Key, T> (o il suo equivalente nodo) prima di controllare l'unicità della chiave. Se la chiave esiste già, questo nodo viene immediatamente scartato, il che significa che qualsiasi costruzione costosa del valore mappato T è stata sprecata.
Il tag std::piecewise_construct altera questo comportamento segnalando al contenitore di trattare i due successivi argomenti tuple come elenchi di argomenti per i costruttori della chiave e del valore, rispettivamente. Avvolgendo gli argomenti del costruttore in std::forward_as_tuple, il contenitore ritarda la vera instanziazione del valore mappato fino all'interno del nodo appena allocato, e solo se la chiave è confermata unica. Questo assicura che il valore venga costruito esattamente una volta, nella sua posizione di memoria finale, e mai se l'inserimento fallisce.
In una piattaforma di trading ad alta frequenza, avevamo bisogno di memorizzare nella cache oggetti Order deserializzati (strutture pesanti contenenti vettori e stringhe) in un std::map<OrderID, Order>. L'implementazione iniziale utilizzava orders.emplace(id, DeserializeOrder(buffer)). La profilazione ha rivelato che durante i picchi di mercato, il 15% del tempo CPU veniva sprecato costruendo oggetti Order per ID duplicati che venivano immediatamente scartati dalla logica di rifiuto della mappa.
Soluzione 1: Controllo e poi inserimento. Abbiamo considerato di controllare esplicitamente if (orders.find(id) == orders.end()) prima di chiamare emplace. Questo evitava costruzioni sprecate ma richiedeva due attraversamenti dell'albero—uno per il find e un altro per l'emplace—raddoppiando il costo di confronto e danneggiando la località della cache.
Soluzione 2: Estrazione manuale del nodo. Abbiamo esplorato la creazione manuale di un std::map::node_type con orders.extract(id) e reinserendolo se vuoto, ma questo richiedeva di pre-costruire l'Order al di fuori della mappa per popolare il nodo, reintroducendo il problema originale.
Soluzione 3: std::piecewise_construct. Abbiamo adottato orders.emplace(std::piecewise_construct, std::forward_as_tuple(id), std::forward_as_tuple(buffer)). Questo ha ritardato la deserializzazione fino a quando il nodo era garantito essere inserito. Sebbene questo risolvesse il problema delle prestazioni, la sintassi era verbosa e soggetta a errori riguardo alla durata degli argomenti.
Approccio scelto e risultato: Alla fine, abbiamo migrato a C++17 e usato orders.try_emplace(id, buffer). Questo forniva la stessa garanzia di efficienza—costruendo l'Order solo in caso di inserimento riuscito—con una sintassi più pulita e un rischio ridotto di riferimenti pendenti. La latenza del sistema è diminuita del 12% durante il carico di picco.
Perché deve essere utilizzato std::forward_as_tuple invece di std::make_tuple quando si preparano gli argomenti per std::piecewise_construct?
std::make_tuple crea una tupla decadenza dei suoi argomenti; copia o sposta valori nello spazio di archiviazione della tupla. Se il tipo mappato non è copiabile o se si stanno passando oggetti grandi, make_tuple fallisce nella compilazione o comporta un sovraccarico di copia non necessario. std::forward_as_tuple crea una tupla di riferimenti (lvalue o rvalue) che preservano la categoria di valore originale, consentendo un perfetto forwarding direttamente nel costruttore dell'oggetto senza copie intermedie.
Quando si utilizza std::piecewise_construct, perché è fondamentale garantire che i riferimenti avvolti da std::forward_as_tuple rimangano validi fino al completamento dell'inserimento?
forward_as_tuple non estende la durata dei temporanei passati; cattura semplicemente i riferimenti. Se si scrive map.emplace(std::piecewise_construct, std::forward_as_tuple(CreateTempKey()), std::forward_as_tuple(args...)), il temporaneo restituito da CreateTempKey() viene distrutto alla fine dell'espressione completa, prima che emplace tenti internamente di costruire il nodo. Questo lascia la tupla con un riferimento pendente, risultando in un comportamento indefinito quando il costruttore accede alla chiave.
In che modo std::map::try_emplace si differisce dall'idioma emplace + piecewise_construct riguardo alla gestione della chiave stessa?
Mentre piecewise_construct può ritardare la costruzione sia della chiave che del valore, try_emplace separa esplicitamente la chiave dagli argomenti di costruzione del valore. try_emplace prende la chiave per riferimento (o valore) e inoltra solo gli argomenti rimanenti al costruttore del tipo mappato se l'inserimento ha successo. Questo significa che try_emplace non può costruire la chiave in loco da più argomenti—richiede che l'oggetto chiave esista già o sia costruibile da un singolo argomento—mentre piecewise_construct può ritardare la costruzione di entrambi i componenti. Tuttavia, try_emplace elimina la verbosità sintattica e i rischi per la durata della gestione manuale delle tuple.