std::variant был введен в C++17 как безопасная альтернатива объединению, предназначенная для замены ненадежных и управляемых вручную объединений в стиле C. Он обеспечивает инвариант, который всегда гарантирует наличие ровно одного из указанных альтернативных типов, предоставляя типобезопасность на этапе компиляции и интуитивную семантику значений. Эта конструкция теоретически гарантирует, что операции, такие как std::visit или std::get, всегда имеют действительный тип для работы.
Состояние valueless_by_exception представляет собой специфический режим отказа, при котором вариант не содержит значения из-за исключения, произошедшего во время операций изменения типа. Эта ситуация возникает, когда вариант должен уничтожить свой текущий альтернативный тип, чтобы освободить место для нового, но последующая конструкция нового альтернативного типа выбрасывает исключение. В результате объект оказывается без действительного активного члена, временно нарушая стандартный инвариант варианта.
Решение, предложенное стандартом, заключается в том, чтобы разрешить это единственное недопустимое состояние, специально для поддержания основных гарантий безопасности при исключениях. Находясь в этом состоянии, вариант остается возможным для разрушения и присвоения, что позволяет очищать ресурсы и вставлять новые значения в память. Для полного восстановления из этого состояния необходимо успешно присвоить или разместить новое значение, что восстанавливает инвариант, установив действительный альтернативный тип и сбросив внутреннюю отслеживающую информацию о состоянии.
std::variant<std::string, int> v = "hello"; try { v.emplace<std::string>(10000000, 'x'); // может выбросить bad_alloc } catch (...) { assert(v.valueless_by_exception()); v = 42; // Восстановление: снова действителен }
Рассмотрим систему высокочастотной торговли, обрабатывающую сообщения рыночных данных, представленные как std::variant<PriceUpdate, OrderCancel, TradeExecution>. В условиях ограниченной памяти попытка присвоить большой объект TradeExecution выбрасывает std::bad_alloc после того, как вариант уже уничтожил предыдущий PriceUpdate, чтобы освободить место. Эта последовательность приводит к тому, что недействительный вариант проходит через конвейер, потенциально вызывая каскадные сбои, если код downstream предполагает наличие действительных данных.
Одним из решений было обернуть каждый доступ к варианту проверками valueless_by_exception() и логикой ручного восстановления перед любыми операциями посещения или извлечения. Этот подход обеспечивал явную безопасность от неопределенного поведения, но загромождал код защитными проверками на каждой точке использования, значительным образом ухудшая читаемость и увеличивая неприемлемую задержку в критическом торговом процессе.
Другой подход состоял в использовании std::optional<std::variant<...>> для выноса пустого состояния за пределы самого варианта. Хотя это сохраняло внутренний инвариант варианта, гарантируя, что внутренний вариант всегда содержит действительный тип, это вводило второй уровень косвенности и требовало двойного разыменования для каждого доступа, усложняя API и потенциально влияя на локальность кеша во время обработки с высокой пропускной способностью.
Команда в конечном итоге выбрала std::monostate как первый альтернативный тип в списке типов варианта, эффективно зарезервировав явное "пустое" состояние внутри обычной типовой системы варианта. Этот выбор полностью исключил возможность состояния без значения, потому что вариант всегда мог вернуться к хранению std::monostate вместо того, чтобы стать недействительным, обеспечивая, что index() всегда возвращает действительную позицию, а std::visit всегда успешно направляется либо к реальным данным, либо к обработчику пустого состояния.
Результатом стало надежное средство обработки сообщений, которое справлялось с отказами выделения памяти, переходя к альтернативе monostate, а не в состояние исключения. Эта конструкция поддерживала строгую безопасность типов без необходимости выполнения проверок на наличие состояния без значения во время выполнения или страданий от накладных расходов на двойную косвенность. Разработчики могли полагаться на то, что вариант всегда может быть посещен, а обработчик monostate выполняет функцию no-op или стандартного поведения для пустых сообщений.
Почему std::variant допускает состояние valueless_by_exception, несмотря на нарушение общего принципа проектирования о том, что вариант всегда должен содержать один из своих указанных типов?
Стандарт придает приоритет высокой безопасности при исключениях в ущерб поддержанию строгого инварианта любой ценой. При изменении хранящейся альтернативы вариант должен уничтожить старое значение перед тем, как создать новое, чтобы предотвратить утечки ресурсов или проблемы с двойным владением. Если эта новая конструкция выбрасывает исключение, вариант не может вернуться к предыдущему состоянию, поскольку это хранилище уже уничтожено, и не может завершить переход в новое состояние. Состояние valueless_by_exception служит необходимым выходом, указывая на то, что объект подлежит разрушению и присвоению, но не содержит действительной альтернативы, предотвращая неопределенное поведение, которое могло бы произойти, если бы предположить, что старое значение все еще существует, или оставляя хранилище неинициализированным.
Как ведет себя std::visit, когда его вызывают для варианта, который вошел в состояние valueless_by_exception, и почему это отличается от доступа к варианту, содержащему std::monostate?
std::visit сразу выбрасывает std::bad_variant_access, когда сталкивается с недействительным вариантом, потому что активный индекс типа равен variant_npos, который не соответствует ни одной перегрузке посетителя. Это принципиально отличается от std::monostate, который является законным, хотя и пустым типом, занимающим конкретную индексированную позицию в списке типов варианта. Посетитель может предоставить конкретную перегрузку для std::monostate, чтобы обрабатывать пустые состояния плавно в рамках нормального управления потоком. Состояние без значения представляет собой истинное условие ошибки, при котором информация о типе полностью потеряна, в то время как monostate представляет собой действительное, преднамеренное пустое состояние в рамках типовой системы, которое участвует в механизме направления посещения.
Может ли вариант восстановиться из состояния valueless_by_exception, не разрушая и не восстанавливая сам объект варианта, и какие конкретные операции способствуют этому восстановлению?
Да, восстановление возможно с помощью операций присвоения или emplace без необходимости разрушать обертку варианта. Когда вы выполняете v = T{} или v.emplace<T>(args), и конструкция типа T проходит успешно, вариант выходит из состояния без значения и содержит новый тип. Это работает, потому что эти операции определены для установления новой активной альтернативы, эффективно реинициализируя память действительным значением и сбрасывая внутренний индекс с variant_npos на позицию T. Простое чтение из варианта или вызов наблюдателей без модификации не изменит состояние; только успешная операция, которая помещает новое значение в память, может восстановить классный инвариант и вернуть флаг без значения обратно в состояние "ложь".