static_cast：编译期的”合理转换”#

static_cast 是最常用的一种，它在编译期做类型检查，确保转换是”有意义的”。

1
// 数值类型之间的转换
2
double d = 3.14;
3
int i = static_cast<int>(d);  // 截断为 3，合法
4

5
// 父类指针 -> 子类指针（向下转型）
6
class Animal {};
7
class Dog : public Animal {};
8

9
Animal* a = new Dog();
10
Dog* dog = static_cast<Dog*>(a);  // 编译通过，但不验证运行时类型

注意最后这个例子：如果 a 实际上指向的不是 Dog 对象，static_cast 不会告诉你，你拿到的是一个悬空指针，后续行为是未定义行为（UB）。

使用场景：数值类型转换、已知安全的继承体系转换、void* 和具体类型之间的转换。

dynamic_cast：运行期的”安全向下转型”#

dynamic_cast 专门用于继承体系中的向下转型（从父类到子类）。它在运行时检查对象的实际类型：

1
class Animal { virtual void speak() {} };  // 必须有虚函数
2
class Dog : public Animal {};
3
class Cat : public Animal {};
4

5
Animal* a = new Cat();
6

7
Dog* dog = dynamic_cast<Dog*>(a);  // 转型失败，返回 nullptr
8
if (dog == nullptr) {
9
    // 走到这里，因为 a 实际上是 Cat
10
}
11

12
Cat* cat = dynamic_cast<Cat*>(a);  // 成功

如果转型的目标是引用而不是指针，失败时会抛出 std::bad_cast 异常：

1
try {
2
    Dog& dog = dynamic_cast<Dog&>(*a);  // 抛异常
3
} catch (const std::bad_cast& e) {
4
    // 捕获到
5
}

代价：dynamic_cast 依赖 RTTI（Run-Time Type Information），有运行时开销——它需要在对象的虚函数表里查类型信息。在性能敏感的 hot path 里要谨慎使用。

使用场景：你真的不确定对象的动态类型，需要安全地尝试向下转型的时候。

reinterpret_cast：告诉编译器”别管类型，直接重解释这块内存”#

这是最危险的 cast。它不做任何实际的转换操作——没有任何运行时代码——只是让编译器把某块内存当作另一种类型来解读。

1
int i = 42;
2
// 把 int* 当作 float* 来用——不做任何转换，直接重新解读内存
3
float* fp = reinterpret_cast<float*>(&i);
4
float f = *fp;  // 读出来的是 int 42 的位模式所对应的 float 值

这和 C 语言的强制转换 (float*)&i 等价，完全由程序员自己负责正确性。

reinterpret_cast 的本质：它是纯粹的编译期操作，只改变了编译器对那块内存的”看法”。生成的机器码里，没有任何额外指令——就是把那个地址拿来当别的类型用。

使用场景：底层硬件编程、序列化/反序列化、以及下面要讲的 type punning。

const_cast：添加或去除 const#

const_cast 是四种 cast 里最窄用途的一个，专门用来添加或去除 const 限定符：

1
const int x = 10;
2
int* px = const_cast<int*>(&x);
3
*px = 20;  // 危险！x 本身是 const，这是 UB

const_cast 的合法场景：当你有一个 const 指针，但你确定它指向的对象不是真正的 const，只是接口声明成 const 的（比如调用某个老 C 库时）。如果底层对象真的是 const，通过 const_cast 修改它是 UB。

1
// 合法用法：legacy API 要求非 const，但你知道它不会修改
2
void legacy_print(char* s);  // 老接口
3
const char* msg = "hello";
4
legacy_print(const_cast<char*>(msg));  // 只读，不修改，安全

Strict Aliasing 规则：为什么 reinterpret_cast 是 UB#

C++ 有一条严格别名规则（strict aliasing rule）：编译器可以假设两个不同类型的指针不会指向同一块内存（除了 char* 和 unsigned char*）。

这个规则让编译器能做更激进的优化——如果 float* 和 int* 不可能指向同一块内存，编译器就不需要考虑修改其中一个会影响另一个的情况，可以大胆地重排指令、缓存寄存器。

1
int i = 42;
2
float* fp = reinterpret_cast<float*>(&i);
3
*fp = 1.0f;
4
// 编译器（在开 -O2 的情况下）可能认为 i 还是 42
5
// 因为 strict aliasing 规则说 int* 和 float* 不会别名
6
int j = i;  // 可能仍然是 42，而不是 1.0f 的位模式

实际上，GCC/Clang 在 -O2 下都会执行这种优化，导致这类代码产生非预期的行为。

std::bit_cast：C++20 的正确做法#

1
#include <bit>
2

3
float f = 1.0f;
4
int i = std::bit_cast<int>(f);  // 安全，合法，无 UB

std::bit_cast 要求源类型和目标类型大小相同，且都是 trivially copyable 的。它在编译期就能内联，开销和 memcpy 一样为零，但语义明确、无 UB。

上面的 Quake 代码用现代 C++ 重写：

1
float Q_rsqrt_modern(float number) {
2
    float x2 = number * 0.5F;
3
    float y = number;
4

5
    uint32_t i = std::bit_cast<uint32_t>(y);
6
    i = 0x5f3759df - (i >> 1);
7
    y = std::bit_cast<float>(i);
8

9
    y = y * (1.5F - (x2 * y * y));
10
    return y;
11
}

std::variant：类型安全的 Union（C++17）#

std::variant 是 tagged union 的标准库替代品——它始终知道自己当前持有的是哪种类型，构造和析构都自动处理，不会出现裸 union 那种”写入 float 却读 int”的静默错误。相比裸 union，它有额外的类型标记存储和访问时的分支开销，因此适合不追求极致性能的场合。对于脚本引擎里的动态值类型、协议解析中的多态字段等场景，它是比手写 tagged union 更安全的选择。

std::variant 的完整用法（std::visit、overloaded 模式、std::any）见 std::optional、variant 与 any。

语法#

1
operator TargetType() const { return ...; }

注意没有返回类型写在前面，因为返回类型就是 TargetType 本身，写了反而多余。

隐式转换运算符#

定义了转换运算符之后，对象可以在合适的上下文里直接被当成目标类型用：

1
class Fraction {
2
    int num_, den_;
3
public:
4
    Fraction(int n, int d) : num_(n), den_(d) {}
5

6
    // 隐式转换为 double
7
    operator double() const { return (double)num_ / den_; }
8

9
    // 显式转换为 bool（是否非零）
10
    explicit operator bool() const { return num_ != 0; }
11
};
12

13
Fraction f{1, 2};
14
double d = f;        // OK，隐式调用 operator double()
15
if (f) { ... }      // OK，explicit operator bool 在条件中允许
16
// bool b = f;      // 编译错误，explicit 禁止这种隐式转换

隐式转换的危险#

听起来很方便，但隐式转换是一把双刃剑。假设你定义了 operator int()，那在某个你完全没预期的地方——比如比较运算、函数重载决议——编译器可能悄悄帮你转了，逻辑 bug 就这么出现了，还不一定有编译警告。

std::string 就故意没有提供 operator const char*()，必须显式调用 .c_str()。这不是懒，而是刻意设计：如果有隐式转换，std::string 对象在很多地方会无声地退化成裸指针，造成悬空指针、生命周期问题。

explicit 关键字#

给转换运算符加 explicit，就只允许显式转换，隐式的通通报错：

1
explicit operator bool() const { return num_ != 0; }

加了 explicit 之后，以下三种方式合法：

1
static_cast<bool>(f)  // 显式 cast
2
if (f) { ... }        // if/while 条件——编译器视为显式
3
bool b = (bool)f;     // C 风格显式 cast

但直接隐式用就不行了：

1
bool b = f;  // 编译错误

C++ 标准库大量使用这个模式——std::optional、std::shared_ptr、std::unique_ptr 都定义了 explicit operator bool()，让你可以写 if (ptr) 判空，但不会意外地把智能指针隐式转成 bool 然后用在数值运算里：

1
std::optional<int> opt = 42;
2
if (opt) {           // OK，条件里的 explicit bool 转换
3
    int v = *opt;
4
}
5
// int x = opt + 1;  // 编译错误，不会隐式转成 bool 再转 int

和 explicit 构造函数的关系#

explicit 构造函数和 explicit 转换运算符是同一问题的两面：

• explicit 构造函数：阻止”其他类型 → 本类”的隐式转换
• explicit 转换运算符：阻止”本类 → 其他类型”的隐式转换

两者都是在说：我知道这个转换在语义上是有意义的，但我不想让编译器在背后偷偷帮你做，用的时候请明确表达你的意图。

经验法则：除了 operator bool() 这种几乎总是 explicit 的情况，其他数值类型的转换运算符（operator int()、operator double()）也应该仔细想想是否真的需要隐式——如果不确定，加 explicit 总是更安全的选择。