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 객체를 할당하려고 시도하면 이전 PriceUpdate가 파괴된 후에 std::bad_alloc 예외가 발생합니다. 이 시퀀스는 유효하지 않은 변형이 파이프라인을 통해 전파되어, 하위 코드가 유효한 데이터를 가정할 경우 연쇄 실패를 초래할 수 있습니다.
하나의 솔루션은 모든 변형 접근을 valueless_by_exception() 체크 및 수동 복구 로직으로 감싸는 것이었습니다. 이 접근 방식은 정의되지 않은 동작에 대한 명시적 안전성을 제공하지만, 매 사용 지점에 방어적 검사로 인해 코드베이스가 혼잡해져 가독성을 저하시키고 중요한 거래 경로에서 용납할 수 없는 지연을 초래했습니다.
또 다른 접근 방법으로는 **std::optional<std::variant<...>>**를 사용하여 변형 자체 외부에서 비어 있는 상태를 외부화하는 것이 고려되었습니다. 이는 내부 변형이 항상 유효한 유형을 보유하도록 함으로써 변형의 내부 불변성을 보존했지만, 이중 간접 참조가 필요하고 API 표면을 복잡하게 하여 고처리량 처리 중에 캐시 지역성에 영향을 미칠 수 있습니다.
팀은 궁극적으로 변형 유형 목록의 첫 번째 대안으로 std::monostate를 선택하여 변형의 정상 유형 시스템 내에서 명시적 "빈" 상태를 예약했습니다. 이 선택은 변형이 비유효 상태가 되는 것을 완전히 방지했으며, 항상 std::monostate를 유지할 수 있도록 하여 **index()**가 항상 유효한 위치를 반환하고 std::visit가 항상 실 데이터 또는 빈 상태 처리기로 성공적으로 전송되도록 보장했습니다.
결과적으로 할당 실패를 우아하게 처리하는 강력한 메시지 프로세서가 되었으며, 이는 예외적으로 유효하지 않은 상태가 아닌 단 상태 대안으로 전환했습니다. 이 설계는 유효하지 않은 상태에 대한 런타임 검사를 요구하지 않고도 엄격한 유형 안전성을 유지함으로써 개발자들이 변형이 항상 방문 가능하다는 것을 신뢰할 수 있도록 했습니다. 단 상태 처리기는 빈 메시지에 대한 무효 작업 또는 기본 행동으로 작용했습니다.
이유는 무엇인가? std::variant는 변형이 항상 지정된 유형 중 하나를 가져야 한다는 일반 설계 원칙을 위반함에도 불구하고 valueless_by_exception 상태를 허용합니까?
표준은 강력한 예외 안전성을 유지하는 것을 모든 비용을 감수하고 불변성을 유지하는 것보다 우선합니다. 유지하는 대체를 변경할 때, 자원의 누수 또는 이중 소유권 문제를 방지하기 위해 변형은 이전 값을 파괴한 다음 새 값을 생성해야 합니다. 이 새 생성이 예외를 발생시키면, 변형은 이전 상태로 롤백할 수 없으며, 그 저장소는 이미 파괴되었기 때문입니다. valueless_by_exception 상태는 개체가 파괴 가능하고 재할당 가능하지만 유효한 대체를 보유하지 않음을 나타내는 필요한 탈출구 역할을 합니다. 이 상태는 이전 값이 여전히 존재한다고 가정하거나 저장소가 초기화되지 않은 상태로 남아 있어 생기는 정의되지 않은 동작을 방지합니다.
valueless_by_exception 상태에 진입한 변형에 대해 std::visit가 호출될 때의 동작은 무엇이며, 이는 std::monostate를 보유한 변형에 접근하는 것과 왜 다릅니까?**
std::visit는 valueless 변형을 만날 경우 즉시 std::bad_variant_access를 발생시킵니다. 이는 활성 유형 인덱스가 variant_npos이며, 이는 어떤 방문자 오버로드에도 매핑되지 않기 때문입니다. 이는 특정 인덱스 위치 내에서 합법적이긴 하지만 비어 있는 유형인 std::monostate와 근본적으로 다릅니다. 방문자는 정상 제어 흐름의 일환으로 빈 상태를 우아하게 처리하기 위해 std::monostate에 대해 특정 오버로드를 제공할 수 있습니다. valueless 상태는 유형 정보가 완전히 상실되는 실제 오류 조건을 나타내는 반면, monostate는 방문 발송 메커니즘에 참여하는 유형 시스템 내의 유효하고 의도된 비어 있는 상태를 나타냅니다.
변형은 valueless_by_exception 상태에서 변형 객체 자체를 파괴하고 재구성하지 않고 복구할 수 있습니까? 그리고 이러한 복구를 촉진하는 특정 작업은 무엇입니까?
예, 복구는 변형 포장을 파괴할 필요 없이 할당 또는 emplace 작업을 통해 가능합니다. v = T{} 또는 **v.emplace<T>(args)**를 실행하고 유형 T의 생성이 성공하면 변형은 비유효 상태에서 벗어나 새 유형을 보유하게 됩니다. 이는 이러한 작업이 새로운 활성 대체를 설정하도록 정의되어 있으며, 유효한 값으로 저장소를 재초기화하고 내부 인덱스를 variant_npos에서 T의 위치로 재설정하기 때문입니다. 변형에서 읽거나 비수정 관찰자를 호출하는 것만으로는 상태가 변경되지 않으며, 새 값을 저장소에 배치하는 성공적인 작업만이 클래스 불변성을 복원하고 유효하지 않은 플래그를 false로 재설정할 수 있습니다.