Voor C++20 stond de Empty Base Optimization (EBO) lege basisklassen toe om geheugenadressen te delen met afgeleide klassengegevensleden, waardoor effectief nul opslag werd verbruikt. Echter, gegevensleden moesten strikt unieke adressen en niet-nul-grootte hebben, waardoor stateless allocators in containers zoals std::map gedwongen werden om ofwel knooppuntgroottes te vergroten of afhankelijk te zijn van fragiele privé-erfelijkheid. Het [[no_unique_address]] attribuut staat expliciet toe dat een niet-statische gegevenslid nul bytes in beslag neemt als het type leeg is, waardoor samenstelling boven erfelijkheid voor allocatoropslag mogelijk wordt gemaakt terwijl de optimale geheugendichtheid in STL containers behouden blijft.
Het C++98-allocator model gebruikte voornamelijk stateless functors, waarbij EBO via erfelijkheid de standaardtechniek was om opslag overhead in standaardcontainers te vermijden. Toen C++11 scoped allocators en geavanceerde allocator propagatie-eigenschappen introduceerde, nam de complexiteit van het erven van potentieel stateful allocators toe, wat het risico van ongedefinieerd gedrag of indelingsinefficiënties met zich meebracht bij het wisselen tussen varianten. C++20 standaardiseerde het [[no_unique_address]] attribuut om taalsupport voor nul-overhead samenstelling te bieden, in lijn met het Zero-overhead principe zonder fragiele erfelijkheidshierarchieën die klassinterfaces ingewikkeld maakten.
Het C++ objectmodel vereist dat complete objecten en potentieel overlappende subobjecten verschillende niet-nul groottes en unieke adressen hebben, wat voorkomt dat twee gegevensleden van dezelfde klasse geheugenlocaties delen, zelfs als hun types leeg zijn. Voor knoop-gebaseerde containers zoals std::list of std::map slaat elk knooppunt doorgaans een allocatore-instance op; zonder optimalisatie voegt een stateless allocator minimaal één byte toe (afgerond op de uitlijningsgrootte), wat het geheugenverbruik aanzienlijk verhoogt voor miljoenen kleine knooppunten. Traditionele oplossingen maakten gebruik van privé-erfelijkheid, wat de klassehiërarchieën ingewikkeld maakte en het gemakkelijk vervangen van allocators door stateful alternatieven bemoeilijkte zonder de sjabloonstructuur te herontwerpen.
Het [[no_unique_address]] attribuut geeft aan de compiler door dat een gegevenslid geen unieke adres vereist, waardoor het op dezelfde geheugenlocatie kan worden geplaatst als een ander subobject als het type van het lid een lege triviaal kopieerbare klasse is. Dit stelt containerimplementators in staat om allocators als directe leden te declareren terwijl de opslagkosten voor stateless types nul blijven, waarbij de compiler automatisch de padding en indeling aanpast. Het attribuut behoudt strikte aliasingregels en semantiek van objectlevensduur, en versoepelt alleen de beperkingen van adresuniekheid specifiek voor het geannoteerde lid.
#include <iostream> #include <memory> #include <cstdint> // Voorbeeld van een stateless allocator template <typename T> struct EmptyAllocator { using value_type = T; EmptyAllocator() = default; template <typename U> EmptyAllocator(const EmptyAllocator<U>&) {} T* allocate(std::size_t n) { return std::allocator<T>().allocate(n); } void deallocate(T* p, std::size_t n) { std::allocator<T>().deallocate(p, n); } // Leeg type bool operator==(const EmptyAllocator&) const = default; }; // Knoop met [[no_unique_address]] template <typename T, typename Alloc = EmptyAllocator<T>> struct NodeOptimized { [[no_unique_address]] Alloc allocator; // Nul bytes als Alloc leeg is T value; NodeOptimized* next; explicit NodeOptimized(const T& val) : value(val), next(nullptr) {} }; // Knoop zonder optimalisatie (ter vergelijking) template <typename T, typename Alloc = EmptyAllocator<T>> struct NodeNaive { Alloc allocator; // Altijd 1+ bytes T value; NodeNaive* next; explicit NodeNaive(const T& val) : value(val), next(nullptr) {} }; int main() { std::cout << "Geoptimaliseerde knoopgrootte: " << sizeof(NodeOptimized<int>) << " bytes "; std::cout << "Naïeve knoopgrootte: " << sizeof(NodeNaive<int>) << " bytes "; // Op typische implementaties zal Geoptimaliseerd 16 bytes zijn (8+4+4 of vergelijkbaar) // terwijl Naïef 24 bytes zal zijn (1 aangepast naar 8 + 8 + 4 + padding) return 0; }
In een low-latency handelsinfrastructuurproject moest het team een aangepaste intrusive red-black tree implementeren voor ordermatching, waarbij elk knooppunt een limietorder vertegenwoordigde. Het systeem vereiste inplugbare geheugenstrategieën: een stack allocator voor gepoolde vaste grootte blokken gedurende de handelsuren en std::allocator voor back-testing scenario's.
De initiële implementatie gebruikte privé-erfelijkheid van de allocator om gebruik te maken van Empty Base Optimization, in de veronderstelling dat de standaardallocator nul bytes zou kosten.
// Eerste benadering: op erfelijkheid gebaseerde EBO template <typename T, typename Alloc> class OrderNode : private Alloc { // Ongemakkelijk: Alloc is een basis T data; OrderNode* left; OrderNode* right; Color color; public: // Probleem: Ambiguïteit als Alloc methoden heeft met de namen 'left' of 'color' // Probleem: Kan Alloc niet gemakkelijk als een lid opslaan als stateful };
Deze benadering bleek kwetsbaar. Toen het risicobeheerteam een stateful auditing allocator eiste die het geheugengebruik bijhield, veroorzaakte het overschakelen naar een lidvariabele onmiddellijk een 8-byte inflatie per knooppunt door de uitlijning, waardoor de totale geheugenspecificatie met 40% toenam en de cacheprestaties verslechterden.
Alternatieve oplosing A: Type-geërodeerde opslag met std::variant.
Het team overwoog om ofwel een pointer naar de allocator (voor stateful) of niets (voor stateless) op te slaan met behulp van std::variant of handmatige type-erasure.
Voordelen: Eenduidige interface voor stateful en stateless allocators zonder sjabloonexplosie.
Nadelen: Indirectiekosten voor stateful allocators, en de variant zelf vereiste ten minste één byte (plus uitlijning) voor discriminatoropslag, waardoor de nul-overhead vereiste voor het kritieke pad waar stateless allocators predominant waren, niet werd opgelost.
Alternatieve oplosing B: Sjabloonspecialisatie met verschillende klassen.
Ze evalueerden het specialiseren van de gehele OrderNode-klasse op basis van std::is_empty_v<Alloc>, waarbij ze erfden als deze leeg was en samenstelden als deze stateful was.
Voordelen: Garant voor nul overhead voor het lege geval.
Nadelen: Code duplicatie tussen de twee specialisaties, verdubbelde compilatietijden, en onderhoudsnachtmerries bij het toevoegen van nieuwe knoopvelden, aangezien wijzigingen in beide sjabloonvertakkingen moesten worden weerspiegeld.
Gekozen oplossing en resultaat:
Het team migreerde naar C++20 en paste [[no_unique_address]] toe op het allocatorlid.
template <typename T, typename Alloc> struct OrderNode { [[no_unique_address]] Alloc alloc; // Nul kost als leeg T data; OrderNode* left; OrderNode* right; // ... rest van de implementatie };
Dit ontwerp maakte de noodzaak voor erfelijkheid overbodig terwijl nul bytes overhead voor de productie-stapelallocator behouden bleef. Wanneer de auditing allocator (stateful) werd vervangen, breidde het lid automatisch uit om zijn tellers op te vangen zonder codewijzigingen. Benchmarktests toonden een 15% reductie in cache-misses in vergelijking met de op erfelijkheid gebaseerde versie door betere compileroptimalisaties op de plattere klassehiërarchie, en de codebase werd aanzienlijk beter onderhoudbaar.
Kunnen twee [[no_unique_address]] gegevensleden van hetzelfde lege type hetzelfde geheugenadres bezetten?
Nee, dat kunnen ze niet. Terwijl [[no_unique_address]] de eis voor een uniek adres in relatie tot andere subobjecten verwijdert, vereist C++ nog steeds dat verschillende complete objecten van hetzelfde type verschillende adressen hebben. Als twee leden m1 en m2 van hetzelfde lege klastype geannoteerd zijn, moet de compiler aparte opslag toewijzen (typisch 1 byte elk, onderhevig aan uitlijning) om ervoor te zorgen dat &node.m1 != &node.m2. Het attribuut staat alleen overlap toe met leden van verschillende types of met subobjecten van de basisklasse.
Hoe werkt [[no_unique_address]] samen met offsetof en standaard-indelings typen?
De interactie is subtiel en potentieel gevaarlijk. Als een klasse [[no_unique_address]] leden bevat, kan het nog steeds standaard-indelings zijn, maar het aanroepen van offsetof op een dergelijk lid levert implementatie-gedefinieerde resultaten op als het lid leeg is en overlapt met een ander subobject. Bovendien, omdat de standaard-indeling regels aannemen dat niet-statische gegevensleden verschillende bytes in de declaratievolgorde bezetten, schendt het overlappen van een leeg lid met een daaropvolgend lid technisch de strikte volgorde-aanname die sommige legacy-code maakt. Ontwikkelaars moeten pointerarithmetic op basis van offsetof voor [[no_unique_address]] leden vermijden en in plaats daarvan vertrouwen op std::addressof.
Waarom is [[no_unique_address]] overbodig voor basisklassen en welke risico's vermijdt het vergeleken met erfelijkheid?
Basisklassen kwalificeren van nature voor Empty Base Optimization zonder attributen, aangezien een lege basisklasse subobject is toegestaan om het adres van het eerste niet-statische gegevenslid van de afgeleide klasse te delen. [[no_unique_address]] bestaat specifiek om deze mogelijkheid aan gegevensleden te bieden, waardoor samenstelling mogelijk is. Het gebruik van gegevensleden vermijdt de valkuilen van naam verstoppen en meervoudige erfelijkheidsambiguïteit van privé-erfelijkheid. Bijvoorbeeld, als een container erfde van een allocator die een geneste pointer typedef definieerde, en de container ook zijn eigen pointer type definieerde, zou ongewijzigde lookup worden opgelost naar het basis klasse lid, wat obscure compilatiefouten zou veroorzaken. Gegevensleden met [[no_unique_address]] elimineren deze scopevervuiling terwijl de indelings efficiëntie behouden blijft.