C++11 introduceerde std::unique_ptr en std::shared_ptr ter vervanging van de onveilige std::auto_ptr. Beide ondersteunen aangepaste deleters voor het beheren van niet-geheugenbronnen zoals bestands handles of databaseverbindingen. Hun architecturale benaderingen verschillen echter fundamenteel vanwege hun eigendomsmodellen en prestatievereisten.
std::unique_ptr implementeert exclusieve eigendom en slaat zijn deleter op als onderdeel van zijn type (de tweede template parameter). Als de deleter status houdt, neemt hij ruimte in binnen het unique_ptr-object zelf naast de beheerde pointer. std::shared_ptr implementeert gedeelde eigendom via een controleblok dat op de heap is toegewezen, waar de deleter type-geërodeerd is en apart van het shared_ptr-object wordt opgeslagen.
Dit architecturale verschil leidt tot verschillende grootte-kenmerken. Een std::unique_ptr met een stateless deleter neemt precies dezelfde ruimte in als een raw pointer dankzij de Empty Base Optimization. Omgekeerd behoudt std::shared_ptr een constante grootte (typisch twee pointers) ongeacht de grootte of complexiteit van de deleter, omdat de deleter in het afzonderlijk toegewezen controleblok resideert.
#include <memory> #include <cstdio> #include <iostream> struct FileDeleter { void operator()(FILE* fp) const { if (fp) std::fclose(fp); } }; struct StatefulDeleter { int flags = 0xDEAD; void operator()(FILE* fp) const { if (fp) std::fclose(fp); } }; int main() { // unique_ptr met stateless deleter: grootte == pointergrootte (8 bytes op 64-bit) std::unique_ptr<FILE, FileDeleter> up(nullptr); // shared_ptr: constante grootte (16 bytes) ongeacht deleter std::shared_ptr<FILE> sp(nullptr, FileDeleter{}); std::cout << "Uniek (stateless): " << sizeof(up) << " bytes "; std::cout << "Gedeeld (om het even welke deleter): " << sizeof(sp) << " bytes "; // unique_ptr met stateful deleter: grotere grootte (16 bytes: pointer + int + padding) std::unique_ptr<FILE, StatefulDeleter> up2(nullptr, StatefulDeleter{}); std::shared_ptr<FILE> sp2(nullptr, StatefulDeleter{}); std::cout << "Uniek (stateful): " << sizeof(up2) << " bytes "; std::cout << "Gedeeld (stateful): " << sizeof(sp2) << " bytes "; }
Een ontwikkelingsteam moest legacy databaseverbinding handles (void*) beheren die door een C API werden teruggegeven. Deze handles vereisten specifieke schoonmaak via db_disconnect() in plaats van delete. De applicatie creëerde duizenden handles per seconde in strakke lussen, waardoor geheugenafdruk en allocatieprestaties cruciaal waren.
De eerste benadering die werd overwogen was een aangepaste RAII-wrapperklasse ConnectionGuard die de handle opsloeg en db_disconnect() in zijn destructor aanriep. Voordelen omvatten volledige controle over de interface en de mogelijkheid om verbinding-specifieke methoden toe te voegen. Nadelen omvatten aanzienlijke standaardcode voor elke resourcetype, de herinvoering van pointersemantiek en incompatibiliteit met standaardbibliotheekalgoritmen die zijn ontworpen voor slimme pointers.
De tweede oplossing maakte gebruik van std::shared_ptr<void> met een lambda-deleter die de disconnectfunctie vastlegde. Voordelen omvatten onmiddellijke beschikbaarheid met behulp van standaardcomponenten en de toekomstbestendige mogelijkheid om eigendom te delen indien nodig. Nadelen omvatten verplichte heapallocatie voor het controleblok, overhead van atomische referentietelling die niet geschikt is voor unieke eigendom met hoge frequentie, en een vaste objectgrootte van 16 bytes ongeacht de lichte aard van de handle.
De derde benadering maakte gebruik van std::unique_ptr<void, decltype(&db_disconnect)> met een function pointer deleter, of bij voorkeur een stateless functor. Voordelen omvatten nul overhead bij het gebruik van stateless functors dankzij de Empty Base Optimization (overeenkomend met de raw pointergrootte van 8 bytes), geen heapallocaties, en een perfecte uitdrukking van exclusieve eigendomsemantiek. Nadelen omvatten de uitgebreidheid van de typesignatuur en de onmogelijkheid om deleters tijdens runtime te wijzigen.
Het team koos voor de derde oplossing met een stateless functor-deleter. Deze keuze elimineerde heapallocaties volledig, verkleinde de wrappergrootte tot 8 bytes en verwijderde atomische operatie-overhead terwijl automatische schoonmaak behouden bleef.
Het resultaat was een vermindering van 40% in het geheugenverbruik en aanzienlijke latentieverbeteringen in het verbinding poolingsysteem, met uitzondering van veiligheid zonder concessies aan prestaties.
Waarom vereist std::unique_ptr een complete type op het moment van vernietiging bij het gebruik van de standaarddeleter, terwijl std::shared_ptr dat niet doet?
Antwoord: std::unique_ptr met de standaarddeleter roept delete aan op de beheerde pointer. De C++ standaard vereist dat delete op een pointer naar T T gedefinieerd heeft als een compleet type om de destructor aan te roepen en de grootte voor de deallocatie te berekenen. Als de destructor van unique_ptr wordt geïnstantieerd waar T alleen forward-gedeclareerd is, faalt de compilatie. std::shared_ptr vangt de deleter (die weet hoe hij T moet vernietigen) op het moment van constructie in het controleblok. Aangezien de deleter type-geërodeerd is en apart wordt opgeslagen, kan shared_ptr later vernietigd worden waar T onvolledig is. Dit onderscheid is cruciaal voor het Pimpl (Pointer to Implementation) idioom: shared_ptr staat het verbergen van implementatiedetails in bronbestanden toe, terwijl unique_ptr ofwel complete types of expliciet gedefinieerde aangepaste deleters vereist waar de implementatie zichtbaar is.
Waarom ondersteunt std::make_unique geen aangepaste deleters, en wat is de aanbevolen alternatieve?
Antwoord: std::make_unique (geïntroduceerd in C++14) biedt uitzonderingveilige allocatie maar retourneert alleen std::unique_ptr<T> of std::unique_ptr<T[]>, die gebruik maken van std::default_delete. De functie kan het deletertype niet afleiden uit de argumenten omdat het deletertype onderdeel moet zijn van de unique_ptr-template handtekening, en fabrieksfuncties kunnen niet impliciet aangepaste deletertypes afleiden zonder expliciete template parameters. De aanbevolen alternatieve is directe constructie: std::unique_ptr<T, CustomDeleter>(new T(args), CustomDeleter{...}). Deze benadering specificeert expliciet het deletertype in de template, terwijl het aangepaste opruimlogica toelaat, hoewel het handmatige uitzonderingbehandeling of zorgvuldige constructievolgorde vereist om de garanties voor uitzonderingveiligheid te behouden.
Hoe beïnvloedt de Empty Base Optimization de geheugenlay-out van std::unique_ptr bij het gebruik van stateless deleters, en waarom is dit niet beschikbaar voor std::shared_ptr?
Antwoord: std::unique_ptr erft van zijn deleterklasse wanneer de deleter een klasstype is. Als de deleter geen dataleden bevat (stateless), past de C++ de Empty Base Optimization (EBO) toe, waardoor het lege base-subobject nul bytes in beslag neemt. Bijgevolg is sizeof(std::unique_ptr<T, StatelessDeleter>) gelijk aan sizeof(T*), wat leidt tot overhead-vrije abstractie. std::shared_ptr kan EBO niet gebruiken omdat het type-erasure moet ondersteunen: elke shared_ptr van dezelfde T moet dezelfde grootte hebben, ongeacht de deleter. Daarom slaat shared_ptr de deleter op in het heap-toegewezen controleblok in plaats van binnen het shared_ptr-object zelf. Dit ontwerp maakt runtime polymorfisme van deleters mogelijk, maar vereist een heapallocatie en voorkomt de optimalisatie van de stack-ruimte die unique_ptr geniet.