Wymóg wynika z reguł zredukowanego typu w C++ oraz konieczności wyboru usuwacza w czasie kompilacji. Gdy typ tablicy jest przekazywany do szablonu, ulega redukcji do wskaźnika, co odbiera informację o rozmiarze tablicy, która odróżnia alokację skalarną (delete) od alokacji tablicy (delete[]). std::unique_ptr rozwiązuje ten problem poprzez częściową specjalizację szablonu: podstawowy szablon std::unique_ptr<T> używa std::default_delete<T>, wywołując skalarny delete, podczas gdy std::unique_ptr<T[]> inicjalizuje std::default_delete<T[]>, który wywołuje delete[]. Ta jawna składnia zapewnia, że kompilator generuje poprawny kod destrukcji bez introspekcji typu w czasie wykonywania lub narzutu.
Kontekst: Silnik przetwarzania audio o niskim opóźnieniu odbiera buforów próbek PCM z interfejsu sterownika sprzętowego, który zwraca float* alokowane za pomocą new float[buffer_size]. Te bufory muszą przejść przez łańcuch filtrów przetwarzania sygnałowego, zachowując ścisłe ograniczenia czasu rzeczywistego oraz bezpieczeństwo wyjątków.
Problem: Zespół wymagał rozwiązania z inteligentnym wskaźnikiem, które zapewniałoby bezpieczeństwo RAII dla tych tablic C-style, bez wprowadzania narzutu śledzenia rozmiaru/pojemności std::vector, co naruszyłoby wymagania dotyczące wyrównania linii pamięci dla operacji SIMD. Krytycznie, użycie skalarnego delete na pamięci alokowanej w tablicy uszkodziłoby stertę i spowodowałoby awarię potoku audio.
Naga wskaźnik z ręcznym usuwaniem. To podejście wykorzystywało nagie wskaźniki float* z explicite wywołaniami delete[] w każdej ścieżce wyjścia. Zalety: zerowy narzut abstrakcji i bezpośrednia kompatybilność z API sprzętowymi. Wady: nieskuteczne w przypadku wyjątków; jeśli filtr wyrzucił wyjątek podczas przetwarzania, bufor wyciekał, a utrzymanie poprawnej logiki usuwania w dwudziestu różnych etapach filtracji stało się nieodpowiedzialne. Odrzucone ze względu na ryzyko awarii w produkcji.
Kontener std::vector<float>. Owijanie bufory w std::vector zapewniało automatyczne zarządzanie pamięcią i śledzenie rozmiaru. Zalety: bezpieczeństwo wyjątku i dostępność kontroli granic. Wady: std::vector niewłaściwie przechowuje wskaźniki pojemności (zwykle 24 bajty narzutu), co naruszyło kontrakty dotyczące wyrównania DMA o stałej wielkości z sprzętem audio. Dodatkowo, std::vector zakłada mutowalną własność i potencjalną reallocację, co było sprzeczne z pulą buforów o stałej wielkości sterownika.
Specjalizacja std::unique_ptr<float[]>. To rozwiązanie wykorzystało std::unique_ptr<float[]>, które automatycznie inicjalizuje std::default_delete<float[]>. Zalety: zerowy narzut (rozmiar równy jednemu wskaźnikowi), gwarantowane wywołanie delete[], przenośne semantyki dla efektywnych przekazów łańcucha filtrów i zapobieganie kopiowaniu w czasie kompilacji. Wady: traci informację o rozmiarze w czasie wykonywania, co wymaga równoległego śledzenia, a std::make_unique<float[]>(size) inicjalizuje elementy, co może być niepotrzebne dla typów POD.
Decyzja i wynik. Wybraliśmy std::unique_ptr<float[]> w połączeniu z lekkim widokiem podobnym do span do śledzenia rozmiaru. To zapewniło bezpieczeństwo wyjątków bez naruszania wymogów dotyczących wyrównania sprzętowego. System przetwarzał strumienie audio przez miesiące bez wycieków pamięci, a jawna specjalizacja tablicy wykryła krytyczny błąd w czasie kompilacji, gdy deweloper próbował użyć std::unique_ptr<float> z alokacją tablicową, wymuszając poprawną składnię przed czasem wykonywania.
Dlaczego std::unique_ptr<Base[]> odrzuca inicjalizację z new Derived[N], gdy std::unique_ptr<Derived> konwertuje się na std::unique_ptr<Base>?
Typy tablic wykazują niekowariantne zachowanie w przeciwieństwie do pojedynczych wskaźników. Podczas gdy Derived* implicite konwertuje na Base* dzięki dostosowaniu wskaźnika, Derived[] nie może konwertować się na Base[], ponieważ arytmetyka indeksowania tablicy zależy od rozmiaru statycznego typu; dostęp do elementu i w widoku Base[] tablicy Derived[] obliczyłby niepoprawne przesunięcia bajtów. Dlatego specjalizacja tablicowa std::unique_ptr jawnie usuwa konstruktory konwertujące między różnymi typami tablic, aby zapobiec dostępowi do nieprawidłowo wyrównanej pamięci, podczas gdy wersja skalarna pozwala na konwersję (wymagając wirtualnych destruktorów dla bezpieczeństwa).
Jak std::make_unique<T[]>(n) inicjalizuje elementy w porównaniu do std::make_unique<T>(args...), i dlaczego to ogranicza jego zastosowanie?
Przeciążenie tablicowe std::make_unique<T[]>(n) wykonuje inicjalizację wartości dla wszystkich n elementów, co zerowo inicjalizuje skalary lub domyślnie konstruuje obiekty. To różni się od formy skalarnej, która przekazuje argumenty do konstruktora T. To rozróżnienie uniemożliwia użycie std::make_unique dla tablic typów nie-domyślnych, ponieważ nie możesz przekazać argumentów konstruktora dla poszczególnych elementów. Kandydaci często próbują użyć std::make_unique<NonDefaultConstructible[]>(5, args), co powoduje błąd kompilacji, zmuszając do ręcznych pętli lub użycia std::vector z wstawieniem.
Jakie nieokreślone zachowanie ujawnia się, gdy std::unique_ptr<T (skalarne) zarządza pamięcią z new T[N], i dlaczego kompilatory milczą?
Skalarny std::unique_ptr wykorzystuje std::default_delete<T>, który wywołuje delete (skalarne usuwanie). Kiedy jest stosowany do pamięci alokowanej w tablicy z new T[N], stanowi to niedopasowanie, prowadząc do nieokreślonego zachowania — zazwyczaj zwalniając tylko pamięć pierwszego elementu lub uszkadzając metadane alokatora sterty. Kompilatory nie ostrzegają, ponieważ parametr szablonu T ulega redukcji; new T[N] zwraca T*, a system typów traci rozróżnienie tablicy w punkcie konstrukcji std::unique_ptr. Ten cichy sposób awarii jest dokładnie powodem, dla którego std::unique_ptr<T[]> istnieje jako odrębna bezpieczna typowo alternatywa.