Gdy obiekt zostaje zniszczony, a nowy obiekt jest tworzony w tym samym adresie za pomocą placement-new, zasady pochodzenia wskaźników w C++ stwierdzają, że oryginalna wartość wskaźnika nie wskazuje automatycznie na nowy obiekt. Kompilator może założyć, że wskaźniki określonego typu utrzymują swoją tożsamość obiektu przez cały czas życia obiektu, co pozwala na agresywne optymalizacje oparte na analizie aliasów na podstawie typów. std::launder wyraźnie tworzy wskaźnik, który wskazuje na nowy obiekt, skutecznie informując kompilator, że miejsce pamięci teraz zawiera odrębny obiekt o potencjalnie innym typie lub kwalifikacji const/volatile. Bez tej interwencji, dereferencja starego wskaźnika narusza zasady ścisłego aliasingu, co prowadzi do nieokreślonego zachowania, mimo że adres zawiera ważną pamięć.
Rozważmy silnik przetwarzania dźwięku w czasie rzeczywistym, który ponownie wykorzystuje stały zbiór buforów, aby zminimalizować błędy w pamięci podręcznej CPU i uniknąć fragmentacji sterty podczas występów na żywo.
Rozwiązanie 1: Standardowa alokacja w stercie
Początkowy prototyp alokował nowe obiekty ramek audio dla każdego bloku przetwarzania za pomocą new. Choć było to proste, spowodowało to słyszalne zrywania podczas pauz w zbieraniu śmieci i błędy pamięci przy dostępie do nieciągłej pamięci, co czyniło to nieakceptowalnym dla profesjonalnego dźwięku.
Rozwiązanie 2: Placement-new z surowymi wskaźnikami
Zespół przeszedł na wstępnie alokowaną tablicę std::aligned_storage_t i używał placement-new do konstrukcji ramek w miejscu. Jednak po prostu ponownie użyli oryginalnych wartości wskaźników po rekonstrukcji. W zoptymalizowanych kompilacjach z Clang, kompilator założył, że wskaźnik do członka objętości const z poprzedniej ramki pozostaje ważny, co spowodowało, że ponownie używał przestarzałych wartości z rejestrów zamiast ponownie załadować z pamięci, gdzie nowa ramka miała inne dane.
Rozwiązanie 3: Implementacja std::launder
Wprowadzili std::launder po każdej operacji placement-new, aby uzyskać wskaźnik do nowego obiektu. To zmusiło kompilator do rozpoznania, że pamięć obecnie zawiera nowy obiekt o odmiennych wartościach, zapobiegając niepoprawnemu cachowaniu rejestrów członków const z zniszczonych ramek.
To rozwiązanie wyeliminowało zniekształcenia dźwięku, zachowując wydajność zerowej alokacji, osiągając wymagania dotyczące latencji poniżej milisekundy.
Czy std::launder można użyć do zmiany typu aktywnego obiektu bez wywoływania jego destruktora?
Nie, std::launder nie rozszerza ani nie zmienia czasów życia obiektów. Standard wyraźnie wymaga, aby czas życia starego obiektu zakończył się (destruktor został wywołany) i nowy obiekt rozpoczął swoje życie w tej samej pamięci, zanim można zastosować std::launder. Próba „prania” wskaźnika do obiektu, którego czas życia się nie zakończył, prowadzi do nieokreślonego zachowania, ponieważ abstrakcyjna maszyna C++ utrzymuje, że oryginalny obiekt nadal istnieje pod tym adresem.
Czy std::launder modyfikuje wzór bitowy wskaźnika?
Nie, std::launder generuje wartość wskaźnika, która porównuje się równo z oryginalnym adresem, ale niesie różne informacje o pochodzeniu. Chociaż implementacje zazwyczaj zwracają dokładnie ten sam wzór bitowy, operacja nie jest jedynie rzutowaniem—informuje analizę aliasów kompilatora, że ten wskaźnik teraz odnosi się do nowego obiektu. To rozróżnienie staje się krytyczne, gdy kompilator przeprowadza optymalizację całego programu w różnych jednostkach tłumaczenia, śledząc wartości wskaźników przez złożone przepływy kontrolne.
Czy std::launder jest niepotrzebny dla typów, które można łatwo zniszczyć, ponieważ nie mają destruktorów?
Nawet w przypadku typów łatwych do zniszczenia, std::launder jest wymagany zawsze, gdy czas życia obiektu się kończy, a nowy obiekt jest tworzony w tej samej pamięci. Czas życia obiektu kończy się, gdy jego pamięć jest ponownie używana, niezależnie od tego, czy destruktor jest wywoływany. Bez std::launder, kompilator może założyć, że członek const starego obiektu pozostaje niezmienny, gdy jest dostępny przez stary wskaźnik, nawet po użyciu placement-new dla nowego obiektu z różnymi wartościami członków const, co prowadzi do cichych błędów optymalizacyjnych.