std::variant został wprowadzony w C++17 jako alternatywa dla typu bezpiecznego uni, zaprojektowana w celu zastąpienia problematycznych i ręcznie zarządzanych unii w stylu C. Egzekwuje inwariant, że zawsze przechowuje dokładnie jeden z określonych alternatywnych typów, co zapewnia bezpieczeństwo typów w czasie kompilacji oraz intuicyjną semantykę wartości. Ten projekt teoretycznie gwarantuje, że operacje takie jak std::visit lub std::get zawsze mają ważny typ do operacji.
Stan valueless_by_exception reprezentuje specyficzny tryb awarii, w którym wariant nie przechowuje żadnej wartości z powodu wystąpienia wyjątku podczas operacji zmieniających typ. Taka sytuacja powstaje, gdy wariant musi zniszczyć swój obecny alternatywny typ, aby zrobić miejsce dla nowego, ale późniejsze skonstruowanie nowego alternatywnego typu powoduje wyrzucenie wyjątku. W konsekwencji obiekt zostaje bez ważnego aktywnego członka, co tymczasowo łamie standardowy inwariant wariantu.
Rozwiązanie przedstawione przez standard to zezwolenie na ten pojedynczy nieprawidłowy stan, aby utrzymać podstawowe gwarancje bezpieczeństwa wyjątków. W tym stanie wariant pozostaje zdatny do zniszczenia i przypisania, co pozwala na oczyszczenie zasobów i umieszczanie nowych wartości w magazynie. Aby w pełni odzyskać ten stan, należy pomyślnie przypisać lub wprowadzić nową wartość, co przywraca inwariant przez ustalenie ważnej alternatywy i zresetowanie wewnętrznego śledzenia stanu.
std::variant<std::string, int> v = "hello"; try { v.emplace<std::string>(10000000, 'x'); // może wyrzucić bad_alloc } catch (...) { assert(v.valueless_by_exception()); v = 42; // Odzyskanie: ponownie ważny }
Rozważ system handlu o wysokiej częstotliwości przetwarzający wiadomości o danych rynkowych przedstawione jako std::variant<PriceUpdate, OrderCancel, TradeExecution>. W czasie scenariusza ograniczenia pamięci, próba przypisania dużego obiektu TradeExecution powoduje wyrzucenie std::bad_alloc, po tym jak wariant już zniszczył poprzedni PriceUpdate, aby zrobić miejsce. Ta sekwencja prowadzi do propagacji wariantu bezwartościowego przez potok, co może powodować kaskadowe awarie, jeśli kod downstream zakłada, że dane są ważne.
Jedno z rozwiązań polegało na owinięciu każdego dostępu do wariantu w kontrole valueless_by_exception() oraz logikę ręcznego odzyskiwania przed jakimikolwiek operacjami wizytowymi lub pobierającymi. To podejście zapewniało wyraźne zabezpieczenie przed niezdefiniowanym zachowaniem, ale zagracało kod bazowy defensywnymi kontrolami w każdym punkcie użycia, znacząco degradując czytelność i wprowadzając niedopuszczalne opóźnienia w krytycznej ścieżce handlowej.
Inne podejście rozważało użycie std::optional<std::variant<...>> do wyeksportowania stanu pustego poza sam wariant. Chociaż to zachowało wewnętrzny inwariant wariantu, zapewniając, że wewnętrzny wariant zawsze przechowuje ważny typ, wprowadziło to drugą warstwę pośrednictwa i wymagało podwójnego dereferencjonowania przy każdym dostępie, komplikując powierzchnię API i potencjalnie wpływając na lokalność pamięci podręcznej podczas przetwarzania z dużą przepustowością.
Zespół ostatecznie wybrał std::monostate jako pierwszą alternatywę na liście typów wariantu, skutecznie rezerwując wyraźny stan „pusty” w normalnym systemie typów wariantu. Ten wybór całkowicie wyeliminował możliwość stanu bezwartościowego, ponieważ wariant zawsze mógł wrócić do posiadania std::monostate zamiast stawania się bezwartościowym, zapewniając, że index() zawsze zwracał ważną pozycję, a std::visit zawsze skutecznie przekierowywał do danych rzeczywistych lub do obsługi stanu pustego.
Rezultatem był solidny procesor wiadomości, który obsługiwał awarie przydziału w sposób elegancki, przechodząc do alternatywy monostate zamiast stanu nieprawidłowego. Ten projekt utrzymywał ścisłe bezpieczeństwo typów, nie wymagając jednocześnie sprawdzeń w czasie wykonywania dla stanu bezwartościowego ani cierpiąc z powodu nadmiarowego pośrednictwa. Programiści mogli polegać na tym, że wariant zawsze był odwiedzany, a obsługa monostate działała jako no-op lub domyślne zachowanie dla pustych wiadomości.
Dlaczego std::variant zezwala na stan valueless_by_exception, mimo że narusza ogólną zasadę projektowania, że wariant powinien zawsze przechowywać jeden ze swoich określonych typów?
Standard priorytetowo traktuje silne bezpieczeństwo wyjątków nad utrzymywaniem ścisłego inwariantu za wszelką cenę. Kiedy wariant zmienia posiadany alternatywny typ, musi zniszczyć starą wartość przed skonstruowaniem nowej, aby zapobiec wyciekom zasobów lub podwójnym problemom własności. Jeśli nowa konstrukcja powoduje wyrzucenie wyjątku, wariant nie może cofnąć się do poprzedniego stanu, ponieważ ten magazyn jest już zniszczony, ani nie może zakończyć przejścia do nowego stanu. Stan valueless_by_exception służy jako niezbędna klapa bezpieczeństwa, wskazując, że obiekt jest zdatny do zniszczenia i przypisania, ale nie posiada ważnej alternatywy, co zapobiega niezdefiniowanemu zachowaniu, które wynikałoby z udawania, że stara wartość wciąż istnieje lub pozostawienia magazynu niezainicjowanego.
Jak działa std::visit, gdy jest wywoływane na wariancie, który wszedł w stan valueless_by_exception, i dlaczego to różni się od dostępu do wariantu holding std::monostate?
std::visit natychmiast wyrzuca std::bad_variant_access podczas napotkania wariantu bezwartościowego, ponieważ indeks aktywnego typu jest variant_npos, co nie odpowiada żadnemu przeciążeniu odwiedzającemu. To różni się zasadniczo od std::monostate, który jest uznawanym, chociaż pustym typem zajmującym określoną pozycję indeksu w liście typów wariantu. Odwiedzający może dostarczyć konkretne przeciążenie dla std::monostate, aby obsłużyć puste stany w sposób płynny jako część normalnego przepływu kontrolnego. Stan bezwartościowy stanowi prawdziwy warunek błędny, w którym informacja o typie jest całkowicie utracona, podczas gdy monostate reprezentuje ważny, zamierzony pusty stan w systemie typów, który uczestniczy w mechanizmie przekierowywania wizyt.
Czy wariant może odzyskać się z stanu valueless_by_exception bez niszczenia i rekonstruowania samego obiektu wariantu, a jakie konkretne operacje ułatwiają tę regenerację?
Tak, odzyskiwanie jest możliwe poprzez operacje przypisania lub emplace bez potrzeby niszczenia samego opakowania wariantu. Kiedy wykona się v = T{} lub v.emplace<T>(args), a skonstruowanie typu T powiedzie się, wariant opuszcza stan bezwartościowy i przechowuje nowy typ. Działa to, ponieważ te operacje są zdefiniowane, aby ustanowić nową aktywną alternatywę, efektywnie reinitializing magazyn z ważną wartością i resetując wewnętrzny indeks z variant_npos do pozycji T. Jedynie odczyt z wariantu lub wywołanie niezmieniających obserwatorów nie zmieni stanu; tylko pomyślna operacja, która umieszcza nową wartość w magazynie, może przywrócić inwariant klasy i zresetować flagę bezwartościowości na fałsz.