Historia: Przed C++20 deweloperzy polegali na reinterpret_cast, unionach lub std::memcpy, aby reinterpretować reprezentacje obiektów. Metody te either wywoływały niedozwolone zachowanie przez naruszenie zasady ścisłej aliasowania lub zasady aktywnych członków, lub nie miały bezpieczeństwa typów i wsparcia constexpr. Komitet wprowadził std::bit_cast, aby zapewnić dobrze zdefiniowany mechanizm dostępu do reprezentacji obiektów jednego typu jako innego.
Problem: std::bit_cast musi gwarantować, że wzór bitów obiektu źródłowego jest zachowany dokładnie w obiekcie docelowym bez wywoływania niedozwolonego zachowania. Wymaga to, aby typ źródłowy mógł być bezpiecznie kopiowany bajt po bajcie (trywialnie kopiowalny) oraz aby żadne informacje nie zostały utracone ani wymyślone podczas transferu (identyczny rozmiar). Bez tych ograniczeń operacja mogłaby dzielić obiekty, omijać prywatne semantyki kopiowania lub tworzyć nieważne wzory bitów dla typu docelowego.
Rozwiązanie: Standard nakłada wymóg, aby oba typy były trivially copyable (pozwalając na kopiowanie bajtów) i miały identyczne rozmiary. Implementacja wykonuje kopiowanie bitowe równoważne std::memcpy, ale z bezpieczeństwem typów i wsparciem oceny constexpr. To unika problemów ze ścisłym aliasowaniem przy rzutowaniu wskaźników i ograniczeniami aktywnych członków unii, zapewniając przenośny, optymalizowalny prymityw dla przekształcania typów.
struct Packet { uint32_t id; float value; }; static_assert(std::is_trivially_copyable_v<Packet>); Packet p{42, 3.14f}; auto bytes = std::bit_cast<std::array<std::byte, sizeof(Packet)>>(p); Packet restored = std::bit_cast<Packet>(bytes);
W silniku gry wieloosobowej system fizyki generuje struktury Transform, zawierające dane pozycji i rotacji w formacie float. Warstwa sieciowa musi przesyłać je jako surowe bajty z zerowym narzutem na kopiowanie. Początkowa implementacja użyła reinterpret_cast<const std::byte*>(&transform), aby uzyskać sekwencję bajtów, ale naruszała zasady ścisłego aliasowania i powodowała awarie pod agresywną optymalizacją kompilatora (-fstrict-aliasing).
Ręczne wyodrębnianie pól: Serializuj każde pole float osobno za pomocą przesunięć bitowych do bufora bajtowego. To podejście gwarantuje zdefiniowane zachowanie i obsługuje konwersję endianness jawnie. Jednak wymaga setek linii szablonów dla złożonych struktur, jest trudne w utrzymaniu, gdy pola się zmieniają, i wprowadza mierzalny narzut CPU z operacjami pętli na dużych tablicach.
Przekształcanie typów w unii: Zdefiniuj union TransformPayload { Transform t; std::byte bytes[sizeof(Transform)]; } i uzyskaj dostęp do członka bajtów po zapisaniu do członka transform. Mimo że jest wspierane jako rozszerzenie kompilatora w GCC i Clang, narusza to zasadę aktywnego członka standardu C++ (tylko jeden członek unii może być aktywny w danym czasie). Prowadzi to do niedozwolonego zachowania, które objawia się jako niepoprawne wartości bajtów, gdy optymalizacja linku (LTO) jest włączona.
std::memcpy: Skopiuj transformację do tablicy bajtów za pomocą std::memcpy(dst, &transform, sizeof(Transform)). To jest dobrze zdefiniowane dla trywialnie kopiowalnych typów i optymalizuje do jednego rozkazu CPU. Jednak wymaga wcześniej przydzielonej pamięci, brakuje wsparcia constexpr w kontekstach przed C++20 dla operacji odwrotnych i zaciemnia intencje kodu w porównaniu do operacji rzutowania.
std::bit_cast: Bezpośrednio przekształć strukturę za pomocą auto packet = std::bit_cast<std::array<std::byte, sizeof(Transform)>>(transform);. To zapewnia konwersję z typowym wsparciem constexpr, z bezpieczeństwem typów oraz wyraźnym zamiarem, umożliwiając weryfikację struktury pakietów w czasie kompilacji. Wymaga wsparcia C++20 i nakłada wymóg, aby Transform był trywialnie kopiowalny, co już zapewnił system fizyki, a składnia wyraźnie wyraża reinterpretację bitową bez niejednoznaczności rzutowań wskaźników.
Zespół wybrał std::bit_cast po migracji systemu budowania do C++20. Wyeliminowało to niedozwolone zachowanie przy jednoczesnym zachowaniu czystej składni rzutowania unii, a możliwość constexpr pozwoliła na walidację konstrukcji pakietów sieciowych w czasie kompilacji podczas zautomatyzowanego testowania.
Moduł sieciowy przeszedł kontrole UBSan i ASan bez zasad tłumienia. Benchmarki wydajności pokazały identyczną przepustowość jak memcpy (0.3ns na konwersję na x86_64), podczas gdy narzędzia do analizy statycznej nie oznaczały już naruszeń aliasingu. Kod pomyślnie deserializuje 100,000 transformacji na sekundę w produkcji.
Dlaczego std::bit_cast wymaga, aby źródłowe i docelowe typy miały identyczne rozmiary, a co się stanie, jeśli różnice w bajtach wypełniających wystąpią między typami?
Wymóg identycznego rozmiaru zapewnia bijekcyjne mapowanie między wzorami bitowymi; żadne bity nie są ucinane ani wynajdowane. Jeśli rozmiary się różnią, rzutowanie jest źle uformowane. Bajty wypełniające są zachowane dokładnie tak, jak istnieją w obiekcie źródłowym. Jednak, jeśli typ docelowy ma inne wymagania dotyczące bajtów wypełniających, odczytywanie tych bajtów wypełniających przez typ docelowy później jest nadal ważne (stają się częścią reprezentacji wartości obiektu docelowego), ale wartości są niesprecyzowane. Oznacza to, że std::bit_cast może kopiować wypełnienia, ale nie możesz przenośnie interpretować bajtów wypełniających jako mających określone wartości.
Jak std::bit_cast różni się od reinterpret_cast pod względem długości życia obiektu i czasu przechowywania?
reinterpret_cast tworzy alias do tej samej lokalizacji pamięci, co potencjalnie narusza zasadę ścisłego aliasowania, jeśli typy są niepowiązane, i nie tworzy nowego obiektu. std::bit_cast koncepcyjnie tworzy nowy obiekt docelowego typu z automatycznym czasem przechowywania (lub constexpr czasem przechowywania, jeśli używane w stałym wyrażeniu), kopiując wzór bitów z źródła. Nie tworzy aliasu; źródło i cel są odrębnymi obiektami. Ta różnica pozwala na użycie std::bit_cast w kontekstach constexpr, gdzie reinterpret_cast jest zabronione, ponieważ nie wymaga rzutowania przez wskaźniki, które mogłyby umknąć stałej ocenie.
Czy std::bit_cast może być użyty do rzutowania wskaźnika na liczbę całkowitą o tym samym rozmiarze i dlaczego może to prowadzić do wyników zdefiniowanych przez implementację mimo że jest poprawne?
Tak, jeśli sizeof(T*) == sizeof(U), std::bit_cast może konwertować między nimi, ponieważ wskaźniki są trywialnie kopiowalne. Jednak wynik jest zdefiniowany przez implementację, ponieważ standard nie nakłada obowiązku specyficznej reprezentacji dla wartości wskaźników (np. adresowanie segmentowane, wskaźniki oznaczone). Chociaż bity są zachowane dokładnie, interpretowanie tych bitów jako liczby całkowitej lub przekształcanie ich z powrotem na wskaźnik daje wyniki zdefiniowane przez implementację. To różni się od reinterpret_cast, które gwarantuje możliwość konwersji silikonowej dla wskaźników do liczb całkowitych i z powrotem (jeśli typ całkowity jest wystarczająco duży), ale std::bit_cast traktuje wskaźnik jako worek bitów, tracąc informacje o pochodzeniu, które kompilator wykorzystuje do analizy aliasowania.