std::variant fue introducido en C++17 como una alternativa de unión segura para tipos, diseñada para reemplazar las uniones de estilo C que son propensas a errores y gestionadas manualmente. Impone el invariante de que siempre contiene exactamente uno de sus tipos alternativos especificados, proporcionando seguridad de tipo en tiempo de compilación y semántica de valor intuitiva. Este diseño garantiza teóricamente que operaciones como std::visit o std::get siempre tengan un tipo válido sobre el cual operar.
El estado valueless_by_exception representa un modo de falla específico donde el variante no contiene valor debido a una excepción que ocurre durante operaciones de cambio de tipo. Esta situación ocurre cuando el variante debe destruir su alternativa actual para hacer espacio para una nueva, pero la construcción subsiguiente de la nueva alternativa lanza una excepción. Como resultado, el objeto queda sin un miembro activo válido, rompiendo temporalmente el invariante de la variante estándar.
La solución proporcionada por el estándar es permitir este estado inválido singular específicamente para mantener las garantías básicas de seguridad ante excepciones. Mientras esté en este estado, el variante sigue siendo destructible y asignable, permitiendo que los recursos sean liberados y nuevos valores sean colocados en el almacenamiento. Para recuperarse completamente de esta condición, uno debe asignar o emplacear con éxito un nuevo valor, lo que restaura el invariante al establecer una alternativa válida y restablecer el seguimiento del estado interno.
std::variant<std::string, int> v = "hola"; try { v.emplace<std::string>(10000000, 'x'); // puede lanzar bad_alloc } catch (...) { assert(v.valueless_by_exception()); v = 42; // Recuperación: válido de nuevo }
Considera un sistema de trading de alta frecuencia que procesa mensajes de datos de mercado representados como std::variant<PriceUpdate, OrderCancel, TradeExecution>. Durante un escenario con restricciones de memoria, un intento de asignar un gran objeto TradeExecution lanza std::bad_alloc después de que el variante ya haya destruido el anterior PriceUpdate para hacer espacio. Esta secuencia resulta en un variante sin valor propagándose a través del pipeline, potencialmente causando fallas en cascada si el código subsiguiente asume que los datos válidos están presentes.
Una solución implicó envolver cada acceso al variante con controles valueless_by_exception() y lógica de recuperación manual antes de cualquier operación de visita o recuperación. Este enfoque proporcionó seguridad explícita contra comportamientos indefinidos, pero ensució la base de código con verificaciones defensivas en cada punto de uso, degradando significativamente la legibilidad e introduciendo una latencia inaceptable en la ruta crítica de trading.
Otro enfoque consideró el uso de std::optional<std::variant<...>> para externalizar el estado vacío fuera del variante mismo. Si bien esto preservó el invariante interno del variante al garantizar que el variante interno siempre contuviera un tipo válido, introdujo una segunda capa de indirection y requería doble desreferencia para cada acceso, complicando la superficie de la API y potencialmente impactando la localidad de caché durante el procesamiento de alto rendimiento.
El equipo finalmente eligió std::monostate como la primera alternativa en la lista de tipos del variante, reservando efectivamente un estado de "vacío" explícito dentro del sistema de tipos normal del variante. Esta elección eliminó completamente la posibilidad del estado sin valor porque el variante siempre podría volver a sostener std::monostate en lugar de volverse sin valor, asegurando que index() siempre devolviera una posición válida y que std::visit siempre despachara correctamente a datos reales o al manejador de estado vacío.
El resultado fue un procesador de mensajes robusto que manejó fallas de asignación de manera elegante al transitar a la alternativa monostate en lugar de caer en un estado inválido. Este diseño mantuvo una estricta seguridad de tipo sin requerir verificaciones en tiempo de ejecución por valuelessness ni sufrir la sobrecarga de doble indirection. Los desarrolladores podían confiar en que el variante siempre sería visitable, con el manejador monostate actuando como un no-op o comportamiento por defecto para mensajes vacíos.
¿Por qué permite std::variant el estado valueless_by_exception a pesar de violar el principio de diseño general de que un variante siempre debería sostener uno de sus tipos especificados?
El estándar prioriza una fuerte seguridad ante excepciones sobre mantener el estricto invariante a toda costa. Al cambiar la alternativa sostenida, el variante debe destruir el viejo valor antes de construir el nuevo para evitar fugas de recursos o problemas de doble propiedad. Si esta nueva construcción lanza, el variante no puede retroceder al estado anterior porque ese almacenamiento ya ha sido destruido, ni puede completar la transición al nuevo estado. El estado valueless_by_exception sirve como una salida necesaria que indica que el objeto es destructible y asignable pero no contiene una alternativa válida, evitando comportamientos indefinidos que resultarían de pretender que el antiguo valor aún existe o dejar el almacenamiento sin inicializar.
¿Cómo se comporta std::visit cuando se invoca en un variante que ha ingresado al estado valueless_by_exception, y por qué esto difiere de acceder a un variante que contiene std::monostate?
std::visit lanza inmediatamente std::bad_variant_access al encontrar un variante sin valor porque el índice de tipo activo es variant_npos, que no se mapea a ninguna sobrecarga de visitante. Esto difiere fundamentalmente de std::monostate, que es un tipo legítimo aunque vacío que ocupa una posición de índice específica dentro de la lista de tipos del variante. Un visitante puede proporcionar una sobrecarga específica para std::monostate para manejar estados vacíos de manera elegante como parte del flujo de control normal. El estado sin valor representa una verdadero condición de error donde la información de tipo se pierde completamente, mientras que monostate representa un estado vacío válido e intencionado dentro del sistema de tipos que participa en el mecanismo de despacho de visitas.
¿Puede un variante recuperarse del estado valueless_by_exception sin destruir y reconstruir el objeto variante en sí, y qué operaciones específicas facilitan esta recuperación?
Sí, la recuperación es posible a través de operaciones de asignación o emplace sin necesidad de destruir el envoltorio variante en sí. Cuando ejecutas v = T{} o v.emplace<T>(args), y la construcción del tipo T tiene éxito, el variante sale del estado sin valor y sostiene el nuevo tipo. Esto funciona porque estas operaciones están definidas para establecer una nueva alternativa activa, efectivamente reinicializando el almacenamiento con un valor válido y restableciendo el índice interno de variant_npos a la posición de T. Simplemente leer desde el variante o llamar a observadores no modificadores no cambiará el estado; solo una operación exitosa que coloque un nuevo valor en el almacenamiento puede restaurar el invariante de la clase y restablecer la bandera de valueless a falsa.