C++11 wprowadziło std::unique_ptr i std::shared_ptr jako zamienniki dla niebezpiecznego std::auto_ptr. Oba zapewniają wsparcie dla własnych deleterów do zarządzania zasobami, które nie są pamięciami, takimi jak uchwyty plików czy połączenia z bazą danych. Jednak ich podejścia architektoniczne różnią się fundamentalnie ze względu na modele własności i wymagania dotyczące wydajności.
std::unique_ptr wdraża wyłączną własność i przechowuje swój deleter jako część swojego typu (drugi parametr szablonu). Jeśli deleter ma stan, zajmuje przestrzeń wewnątrz obiektu unique_ptr obok zarządzanego wskaźnika. std::shared_ptr wdraża współdzieloną własność za pomocą bloku kontrolnego alokowanego na stercie, gdzie deleter jest erozją typów i przechowywany osobno od obiektu shared_ptr.
Ta różnica architektoniczna prowadzi do odmiennych charakterystyk rozmiaru. std::unique_ptr z deleterem bez stanu zajmuje dokładnie taką samą przestrzeń, jak wskaźnik surowy dzięki Optymalizacji Pustej Bazy. Z drugiej strony, std::shared_ptr utrzymuje stały rozmiar (zazwyczaj dwa wskaźniki) bez względu na rozmiar lub złożoność deletera, ponieważ deleter znajduje się w oddzielnie alokowanym bloku kontrolnym.
#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 z deleterem bez stanu: rozmiar == rozmiar wskaźnika (8 bajtów na 64-bitowych) std::unique_ptr<FILE, FileDeleter> up(nullptr); // shared_ptr: stały rozmiar (16 bajtów) niezależnie od deletera std::shared_ptr<FILE> sp(nullptr, FileDeleter{}); std::cout << "Unikalny (bezstanu): " << sizeof(up) << " bajtów "; std::cout << "Wspólny (dowolny deleter): " << sizeof(sp) << " bajtów "; // unique_ptr z deleterem z stanem: większy rozmiar (16 bajtów: wskaźnik + int + wyrównanie) std::unique_ptr<FILE, StatefulDeleter> up2(nullptr, StatefulDeleter{}); std::shared_ptr<FILE> sp2(nullptr, StatefulDeleter{}); std::cout << "Unikalny (ze stanem): " << sizeof(up2) << " bajtów "; std::cout << "Wspólny (ze stanem): " << sizeof(sp2) << " bajtów "; }
Zespół deweloperów musiał zarządzać uchwytami połączeń do bazy danych (void*), zwracanymi przez API C. Uchwytom tym wymagana była specyficzna procedura czyszczenia przez db_disconnect() zamiast delete. Aplikacja tworzyła tysiące uchwytów na sekundę w ciasnych pętlach, co uczyniło wydajność pamięci i alokacji krytycznym.
Pierwszym rozważanym podejściem była klasa opakowująca RAII ConnectionGuard, która przechowywała uchwyt i wywoływała db_disconnect() w swoim destruktorze. Zalety obejmowały pełną kontrolę nad interfejsem i możliwość dodawania metod specyficznych dla połączenia. Wady dotyczyły znacznej ilości kodu szablonowego dla każdego typu zasobu, ponownego wynajdowania semantyki wskaźników oraz niekompatybilności z algorytmami standardowej biblioteki zaprojektowanymi dla inteligentnych wskaźników.
Drugie rozwiązanie wykorzystywało std::shared_ptr<void> z deleterem lambda, który przechwytywał funkcję rozłączania. Zalety obejmowały natychmiastową dostępność przy użyciu standardowych komponentów oraz przyszłą możliwość współdzielenia własności, jeśli zajdzie taka potrzeba. Wady obejmowały obowiązkową alokację na stercie dla bloku kontrolnego, narzut na atomowe zliczanie referencji, które jest nieodpowiednie dla unikalnej własności o wysokiej częstotliwości, oraz stały rozmiar obiektu wynoszący 16 bajtów, niezależnie od lekkości uchwytu.
Trzecie podejście zastosowało std::unique_ptr<void, decltype(&db_disconnect)> z deleterem wskaźnika funkcji lub, lepiej, bezstanowym funktorem. Zalety obejmowały zerowy narzut przy użyciu bezstanowych funktorów dzięki Optymalizacji Pustej Bazy (dopasowując rozmiar surowego wskaźnika do 8 bajtów), brak alokacji na stercie oraz idealne wyrażenie semantyki wyłącznej własności. Wady obejmowały rozległość podpisu typu oraz niemożność zmiany deleterów w czasie działania.
Zespół wybrał trzecie rozwiązanie z bezstanowym funktorem deleterem. Ten wybór całkowicie wyeliminował alokacje na stercie, zmniejszył rozmiar opakowania do 8 bajtów i usunął narzut operacji atomowych, jednocześnie zapewniając automatyczne czyszczenie.
Rezultatem była 40% redukcja zużycia pamięci i znaczne poprawy opóźnienia w systemie puli połączeń, osiągając bezpieczeństwo wyjątków bez kompromisów w wydajności.
Dlaczego std::unique_ptr wymaga pełnego typu w momencie zniszczenia przy użyciu domyślnego deletera, podczas gdy std::shared_ptr tego nie robi?
Odpowiedź: std::unique_ptr z domyślnym deleterem wywołuje delete na zarządzanym wskaźniku. Standard C++ wymaga, aby delete na wskaźniku do T miał T zdefiniowany jako pełny typ, aby wywołać destruktor i obliczyć rozmiar do oddelegowania. Jeśli destruktor unique_ptr jest instancjonowany tam, gdzie T jest tylko forward-deklawowany, kompilacja kończy się niepowodzeniem. std::shared_ptr przechwytuje deletera (który wie, jak zniszczyć T) w czasie konstrukcji w bloku kontrolnym. Ponieważ deleter jest erozją typów i przechowywany osobno, shared_ptr może być później zniszczony tam, gdzie T jest niekompletny. Ta różnica jest kluczowa dla idiomu Pimpl (Wskaźnik do implementacji): shared_ptr pozwala na ukrycie szczegółów implementacji w plikach źródłowych, podczas gdy unique_ptr wymaga albo pełnych typów, albo jawnych niestandardowych deleterów zdefiniowanych tam, gdzie implementacja jest widoczna.
Dlaczego std::make_unique nie wspiera własnych deleterów, a co jest zalecaną alternatywą?
Odpowiedź: std::make_unique (wprowadzone w C++14) zapewnia alokację bezpieczną dla wyjątków, ale zwraca tylko std::unique_ptr<T> lub std::unique_ptr<T[]>, które korzystają z std::default_delete. Funkcja nie może wydedukować typu deletera z argumentów, ponieważ typ deletera musi być częścią sygnatury szablonu unique_ptr, a funkcje fabryczne nie mogą jawnie wydedukować typów niestandardowych deleterów bez jawnych argumentów szablonu. Zalecaną alternatywą jest bezpośrednia konstrukcja: std::unique_ptr<T, CustomDeleter>(new T(args), CustomDeleter{...}). To podejście jawnie określa typ deletera w szablonie, jednocześnie pozwalając na niestandardową logikę czyszczenia zasobów, chociaż wymaga ręcznego zarządzania wyjątkami lub ostrożnej kolejności konstrukcji w celu zachowania gwarancji bezpieczeństwa wyjątków.
Jak Optymalizacja Pustej Bazy wpływa na układ pamięci std::unique_ptr przy użyciu deleterów bez stanu i dlaczego jest to niedostępne dla std::shared_ptr?
Odpowiedź: std::unique_ptr dziedziczy po klasie deletera, gdy deleter jest typem klasy. Jeśli deleter nie zawiera członów danych (bezstanowy), C++ stosuje Optymalizację Pustej Bazy (EBO), co pozwala na to, aby podobiekt pustej bazy zajmował zero bajtów. W konsekwencji sizeof(std::unique_ptr<T, StatelessDeleter>) równa się sizeof(T*), osiągając zero-narzutowe abstrakcje. std::shared_ptr nie może korzystać z EBO, ponieważ musi wspierać erozję typów: każdy shared_ptr tego samego T musi mieć ten sam rozmiar niezależnie od deletera. Dlatego shared_ptr przechowuje deletera w alokowanym na stercie bloku kontrolnym, a nie wewnątrz obiektu shared_ptr. Ten projekt umożliwia polimorfizm czasowy deleterów, ale wymusza alokację na stercie i uniemożliwia optymalizację przestrzeni stosu, z której korzysta unique_ptr.