为何std::get访问variant失败时抛异常而非未定义行为？有何规避方案？

Great question—this gets to the core of C++'s balance between safety and performance, especially with modern features like std::variant. Let's break this down:

1. Design rationale for throwing exceptions on wrong type access #

std::variant was introduced in C++17 as a type-safe alternative to C-style unions. Unlike raw unions, which let you read any member regardless of what's actually stored (leading to undefined behavior), std::variant is designed to enforce type safety by default. Here's why the exception-based check is the right choice:

• Safety first: The primary goal is to prevent accidental undefined behavior. If you try to access a std::string from a variant that currently holds an int, throwing std::bad_variant_access gives you a clear, catchable error instead of silent corruption, crashes, or unpredictable behavior that's nearly impossible to debug in large codebases.
• Alignment with modern C++ trends: C++ has been moving toward safer defaults over time (think nullptr instead of raw NULL, std::span instead of pointer+size, bounds-checking in std::vector::at()). std::get's exception behavior fits this pattern—providing a safe default that protects beginners and casual users, while letting advanced users opt out if needed.
• Predictability: Exceptions give you a defined failure path. You can catch the exception and handle it gracefully (e.g., log an error, fall back to a default value) instead of your program entering an undefined state.

2. Why undefined behavior isn't the default #

Undefined behavior (UB) in C++ is typically reserved for cases where performance is critical and the cost of checking would be prohibitive, or when the language can't enforce safety without breaking compatibility. For std::variant, this isn't the case:

• UB is too high a cost for a common mistake: Accidentally accessing the wrong type in a variant is a plausible error, especially when working with complex variant types or dynamic data. UB here would lead to bugs that are hard to reproduce and diagnose, which goes against std::variant's purpose of making unions safe.
• The standard provides an escape hatch: If you want to skip the check and accept the risk of UB, you don't have to use std::get. The standard library offers std::get_if, which returns a pointer (nullptr if the type is wrong) instead of throwing. This lets you explicitly choose to skip the check (by dereferencing the pointer without verifying it's non-null), putting the responsibility on you rather than making UB the default.
• Performance isn't the only priority: While performance matters, std::variant is designed to be usable first. The runtime check is usually cheap (just a comparison of the variant's internal type index), and compilers often optimize it away when they can prove the type is correct (e.g., immediately after assigning a value to the variant).

3. How to avoid the runtime check #

If you're in a performance-critical section and can guarantee the variant holds the expected type, here are valid ways to skip the check:

• Use std::get_if with explicit verification (or intentional UB):

  std::variant<int, std::string> v = 42;
  // If you're 100% sure v holds an int, skip the check (UB if wrong)
  int* val_ptr = std::get_if<int>(&v);
  // Optional: Add a debug-time check to catch mistakes early
  assert(val_ptr != nullptr);
  int val = *val_ptr; // No runtime check in release mode (if assert is disabled)
  

• Leverage std::visit for compile-time dispatch:
  std::visit uses a visitor pattern to handle all possible types in the variant. When you use it, the compiler can often optimize away runtime checks because it knows exactly which overload to call based on the variant's current type. For example:

  struct Visitor {
      void operator()(int i) { /* handle int */ }
      void operator()(const std::string& s) { /* handle string */ }
  };
  
  std::variant<int, std::string> v = "hello";
  std::visit(Visitor{}, v); // No runtime type check (optimized away)
  

• Rely on compiler optimizations:
  If your code makes it obvious to the compiler that the variant holds a specific type (e.g., you just assigned the type and there's no branching that could change it), the compiler will often eliminate the runtime check automatically. For example:

  std::variant<int, std::string> v;
  v = 123;
  int x = std::get<int>(v); // Compiler optimizes out the check
  

• Custom variant implementation (last resort):
  If you absolutely need zero overhead and are willing to give up all type safety, you could implement a raw union with a manual type tag. But this defeats the purpose of std::variant and is only recommended if you've profiled your code and confirmed the check is a bottleneck.

内容的提问来源于stack exchange，提问作者Denis Yaroshevskiy