对账系统上线第三天，财务群里甩过来一张截图：一笔单价 19.99 元的订单，系统算出来的分值是 1998，而手工复算应该是 1999。差一分钱。排查了两个小时，算法、数据库字段精度、接口参数全都看了一遍，最后定位到的是一行谁都没在意的代码：int cents = price * 100;。price是double，值并不是 19.99，而是 19.989999999999998436805981327779591083526611328125，乘 100 之后拿到 1998.9999999999998，double转int是按向零截断做的，于是 1998 就这么固定下来了。这行代码没有报错，没有告警，编译期一声不吭。这就是 C++ 类型转换最典型的性格：它把大量语义决定藏在你看不见的地方，隐式转换默默替你签字，显式转换则要你自己承担后果。

C++ 的类型转换分成两条完全不同的路径。一条是编译器在赋值、传参、返回、运算、条件判断这些时机自动插入的隐式转换，另一条是你在代码里明确写下来的显式转换（static_cast、dynamic_cast、const_cast、reinterpret_cast，以及 C 风格的(T)x）。这两条路径背后是同一套类型系统规则，但风险和可读性差了好几个量级。这篇内容适合三类人：刚学完 C++ 基础语法、对int a = 3.9为什么等于 3 还停留在"记住了"层面的新手；写了几年业务代码、被size_t和有符号数坑过一次的中级开发者；以及负责代码评审、想给团队定一套转换规范的技术负责人。下面我会从整型、浮点、自定义类型、四种显式转换、指针与类层次这几个角度把规则拆开，再给出一套可以直接抄进项目的工具代码和评审清单。

1. 从"差一分钱"的 bug 拆开转换的发生时机

1.1 现象背后的真实值：double里没有 19.99

先把那个 bug 完整复现一遍。你可能觉得19.99 * 100 == 1999是常识，但把这段代码跑起来打印高精度值，答案是 1998.9999999999998。原因不是 C++ 有 bug，而是 IEEE 754 双精度浮点数只有 53 位有效二进制位，十进制小数 0.99 在二进制下是无限循环小数，存进去必然被砍掉尾巴。砍完之后得到的近似值略小于真实值，乘 100 正好卡在 1998.9999… 这个位置，向零截断就成了 1998。

这里面其实发生了两次转换。第一次是price * 100，price是double，字面量100是int，两者做乘法之前，int被隐式转换成double，这叫算术转换。第二次是把double结果赋给int变量，这叫浮点到整型的转换，规则是丢弃小数部分向零取整，不是四舍五入，也不是向下取整。很多人以为它等价于floor，其实对负数不成立：static_cast<int>(-3.9)得到 -3，而floor(-3.9)得到 -4。

修正方案有三种，各有取舍：

// 方案一：一开始就用整数分存储，从源头避开浮点 long long cents = std::llround(price * 100); // 需要 <cmath> // 方案二：如果外部接口只能给 double，用舍入函数而不是强制转换 int cents = static_cast<int>(std::lround(price * 100)); // 方案三：用定点数类型（自己实现或引入第三方库），业务层不出现裸 double

我在项目里更倾向方案一。只要金额进入系统的那一刻就换算成整数分，后面所有加减乘除都是整数运算，不会有任何精度漂移。std::llround和std::lround的区别只在于返回类型，前者返回long long，后者返回long，在 Windows 上long是 32 位，金额大了会溢出，所以我会优先用llround。

1.2 编译器会替你做主的六个位置

隐式转换不是随机发生的，它有明确的触发点。把触发点记清楚，写代码时脑子里就会自动亮灯。

1. 初始化与赋值：int a = 3.9;、double d = 5;、char c = 300;。这是最常见的一类。
2. 函数实参传递：void f(double);你传一个int进去，int先转double，形参才拿到值。
3. 函数返回值：double g()里写return 1;，返回值会被转成double再交给调用方。
4. 算术与比较运算的操作数：1 + 2.5、x < y（两侧类型不同），都会先做寻常算术转换统一到公共类型再算。
5. 条件上下文：if (ptr)、while (count--)、!obj、a && b这些位置会做上下文转换到bool。C++11 之后这里还专门给explicit operator bool开了口子，后面会讲。
6. 异常对象匹配与类型擦除：抛出的派生类异常能被catch (const Base&)接住，这里也发生了派生类到基类的转换。

我见过最隐蔽的一例是在第 5 条上。有个同事给一个业务类加了operator bool()用来做"是否有效"的判断，结果代码里写if (a == b)时，a == b被解释成了"两个对象都有效"而不是"两个对象相等"，因为两个bool可以比较。这类问题编译期完全不报，跑起来逻辑是错的。

1.3 标准转换序列：隐式转换不是"随便转"

C++ 标准把隐式转换组织成标准转换序列，顺序大致是：零个或一个左值到右值转换、零个或一个数组到指针/函数到指针转换、零个或一个限定转换（比如int*到const int*）、零个或一个整型提升或整型转换、零个或一个浮点转换。听起来抽象，但它解释了为什么有些代码能编过、有些编不过。

举两个能直接看出来规则作用的例子。第一个是重载决议的优先级：当实参类型和多个重载都能匹配时，编译器按"精确匹配 > 提升 > 转换 > 用户定义转换 > 省略号"的顺序挑。

void f(int); void f(long); f('a'); // 选 f(int)：char 到 int 是【提升】，char 到 long 是【转换】，提升优先

第二个是用户定义转换序列里最多只能有一次用户自定义转换。也就是说，不会出现"对象 A 通过转换运算符变成 B，再通过构造函数变成 C"这种两连跳：

struct A { operator int() const { return 1; } }; struct B { B(int); }; B b1 = A{}; // 错：A -> int（用户定义）+ int -> B（用户定义），两步不许 B b2 = B(static_cast<int>(A{})); // 对：手动拆成两步

这条限制是保护机制。如果没有它，编译器在重载决议时就得搜索任意长度的转换链，编译时间会失控，代码的可预测性也会崩塌。知道了这条规则，遇到"'明明有转换路径却编不过'的情况，就知道应该往哪个方向查了。

2. 整型世界里的隐式转换：位宽和符号的静默战争

2.1 整型提升与寻常算术转换的完整顺序

整型转换分两个层次。第一个层次叫整型提升：所有比int窄的整型（bool、char、signed char、unsigned char、short、unsigned short）在参与运算前，都会先被提升到int（如果int装得下它的所有值），否则提升到unsigned int。最常见的场景是字符运算：

char c = 'A'; int x = c + 1; // c 先提升为 int，再加 1，结果 66

第二个层次是寻常算术转换。当两个操作数类型不同时，按下面的顺序往上爬，爬到两者类型一致为止：

整型的转换等级从高到低大致是：long long/unsigned long long>long/unsigned long>int/unsigned int>short/unsigned short>char/signed char/unsigned char>bool。

第 6 条就是经典的坑源。int和unsigned int做运算时，有符号的那一侧会被转成无符号，负数直接变成巨大的正数。这不是"实现定义"或者"未定义"，这是标准强制规定的行为，所有编译器都必须这么干。

2.2 有符号与无符号混用：最经典的静默错误

-1 > 1u的结果是true。因为-1被转成unsigned int之后是4294967295。这不是冷知识，它在真实代码里出现的频率高得离谱。下面这几段都是我或者同事实际写出来过的：

// 场景一：倒序遍历，容器为空时彻底失控 std::vector<int> v; for (auto i = v.size() - 1; i >= 0; --i) { // auto 推导为 size_t // v 为空时 v.size() - 1 是 SIZE_MAX，i >= 0 恒真，越界访问 } // 场景二：长度校验永远通过 int len = get_length(); if (len < sizeof(buffer)) { // sizeof 是 size_t，len 被转成无符号 // len = -1 时条件也为真，后面 memcpy 直接翻车 } // 场景三：查找失败判定 if (s.find("x") < 0) { // find 返回 size_t，永远不可能是负数，条件恒假 }

正确写法是让两侧类型一致。倒序遍历可以改成：

for (std::size_t i = v.size(); i-- > 0; ) { // 先比较后自减，语义清晰 // 这里 i 的类型始终是 size_t，比较不会升级 } // C++20 起，<iterator> 里还有 std::ssize，直接拿到有符号长度 for (auto i = std::ssize(v) - 1; i >= 0; --i) { }

std::ssize返回ptrdiff_t，在 64 位平台上能覆盖size_t的常用范围，用它做索引可以彻底避开这个坑。但要注意它只在 C++20 之后才有，老项目里得自己写static_cast<std::ptrdiff_t>(v.size())。

如果实在没办法统一类型（比如一方是第三方库的返回类型），C++20 的<utility>提供了安全比较函数：

#include <utility> if (std::cmp_less(len, sizeof(buffer))) { } // 安全，负数会正确判定为小于 if (std::cmp_greater_equal(idx, 0u)) { } // 不用再手动转类型 bool ok = std::in_range<std::size_t>(len); // 直接判断能否安全转换

这三个函数内部会判断符号性并按值域正确比较，比自己手写static_cast靠谱得多。

2.3 窄化、截断与实现定义行为

把宽类型塞进窄类型，高位会被直接砍掉，这叫截断。无符号类型的行为是标准的：按 2 的 N 次方取模。

unsigned char uc = 300; // 300 % 256 = 44，标准保证 unsigned char uc2 = -1; // 也是 255，标准保证

有符号类型的截断在 C++20 之前是"实现定义"的——标准不规定结果，由编译器决定。好消息是 C++20 开始强制要求补码表示，并且转换结果明确规定为按 2 的 N 次方取模，所以signed char sc = 300;现在也是可预测的 44。但大多数项目还在用 C++17 或更早的标准，所以不要依赖这个。

还有一个很多人不知道的点：char的符号性是实现定义的。在 x86 的 Linux 和 Windows 上char默认是有符号的，在部分 ARM 平台和 AIX 上是无符号的。这意味着char c = 200; if (c > 0)在不同平台上结果不同。涉及字节数据时，别用char，用unsigned char或者 C++17 的std::byte。

浮点到整型的转换规则也要拎清楚：

• 小数部分向零截断，不是四舍五入，也不是向下取整。
• 如果截断后的值超出了整型能表示的范围，行为是未定义的。double d = 1e300; int i = static_cast<int>(d);这种代码在不同优化级别下可能给出INT_MIN、0 或者别的垃圾值，编译器有权假设它不会发生，从而做出你完全预料不到的优化。
• 整型转浮点可能丢精度。float只有 24 位有效尾数，16777217转成float会变成16777216.0f。

我在处理外部输入（JSON、网络报文、配置文件）时有一条硬规则：任何从浮点或宽整数转到窄整数的位置，必须先做范围检查。宁可多写三行判断，也不要让未定义行为潜进代码。

3. 自定义类型的隐式转换：构造函数与转换运算符的两张面孔

3.1 转换构造函数：一个参数就是一张入场券

只要一个构造函数能被单个实参调用（参数只有一个，或者除第一个外都有默认值），它同时就定义了一条隐式转换路径。这是 C++ 里最容易被忽视的"隐式接口"。

class Meter { public: Meter(double v) : v_(v) {} double value() const { return v_; } private: double v_; }; void print(Meter m); print(3.5); // 编译通过：3.5 隐式构造出一个临时 Meter 对象

这里的问题在于，Meter表示一个物理单位，从裸double隐式构造出来的东西，语义是模糊的——这个 3.5 是米？还是厘米？还是根本就是误写成Meter的一个无关数值？

判断要不要保留隐式构造，我用一个简单的标准：如果这个类型和源类型之间的转换不会造成语义歧义，就保留；只要有歧义，一律加explicit。标准库自己也是这么做的，std::string从const char*的构造就是隐式的，因为字符串字面量的语义非常明确；而std::vector<int> v = 5;这种就不行，vector的size_type构造函数是explicit的，否则天知道你想干什么。

class Meter { public: explicit Meter(double v) : v_(v) {} double value() const { return v_; } private: double v_; }; print(3.5); // 编译错误，很好 print(Meter{3.5}); // 明确表达意图，通过 print(static_cast<Meter>(3.5)); // 也可以，因为 static_cast 走的是直接初始化

顺便说一个细节：static_cast<Meter>(3.5)是能编过的，因为static_cast到类类型时执行的是直接初始化，而直接初始化允许调用explicit构造函数。真正被explicit挡住的是拷贝初始化（Meter m = 3.5;）和函数传参时的隐式转换。

3.2 operator T()：方便背后的重载歧义

转换运算符是另一张脸。写一个operator T()，就等于告诉编译器"这个类型的对象可以在任何需要 T 的地方出现"。

class Buffer { public: operator const char*() const { return data_; } private: const char* data_ = ""; }; Buffer buf; std::size_t n = strlen(buf); // 能用，看起来很方便 if (buf) { } // 也能用，转成指针判空 buf + 1; // 灾难：这是在拿 const char* 做指针算术

最后一行才是真正的问题。因为隐式转成了指针，buf + 1编译通过，语义却是"把内部缓冲区地址往前挪一个字节"，跟写这段代码的人想的完全不是一回事。这类 bug 不会报错，只会让你在调试器里怀疑人生。

std::string在 C++11 之前就有这个问题，它有个operator const char*()，导致大量意想不到的指针算术和delete误用，C++11 之后改成了data()和c_str()显式调用。这个演变的教训很明确：转换运算符尽量不要隐式。

无条件转bool也危险。标准做法是用explicit operator bool，它在 C++11 引入，配合语言规则的特殊豁免，可以在if、while、!、&&、||、?:这些上下文转换位置使用，但不允许转成int、不允许参与算术：

class Handle { public: explicit operator bool() const noexcept { return fd_ >= 0; } private: int fd_ = -1; }; Handle h; if (h) { } // 可以，上下文转换 bool b = h; // 可以，显式指定了目标类型 bool int n = h + 1; // 编译错误，喜闻乐见

std::unique_ptr、std::shared_ptr、std::optional、std::ifstream全都用了这一招。你自己写资源句柄类的时候，直接照抄这个模式就对了。

3.3 explicit 该加在哪里：一份可执行的判断清单

explicit能加在构造函数上（C++98 起）和转换运算符上（C++11 起）。C++20 还允许写explicit(bool)做条件性 explicit，模板库里用得多。日常业务代码里，我按下面这张表来定：

最后一条要多说一句。给移动构造函数加explicit会让std::vector的push_back、emplace_back在某些场景下无法按预期工作，因为容器内部依赖隐式移动来搬运元素。这是标准里明确允许但实际不该做的事。

当多个转换运算符都存在且等级相同时，重载决议会直接报歧义错误：

struct Value { operator int() const { return 1; } operator unsigned() const { return 1u; } }; void take(long); take(Value{}); // 编译错误：int -> long 和 unsigned -> long 都是【转换】等级

解决办法只有一个：把其中一个改成explicit，调用方手动指定想要哪个。这类错误编译器会直接报出来，算是好事。真正麻烦的是"某个转换运算符存在，导致原本应该报错的代码悄悄编过了"，这种只能靠代码评审和explicit习惯来防。

4. 四种显式转换的能力边界与代价

4.1 static_cast：编译期检查的边界在哪里

static_cast是最常用的显式转换，但它经常被误解成"安全的 C 风格转换"。它实际上只做两件半事：编译期能验证的类型转换、类层次结构内的指针/引用转换（不做运行时检查）、以及调用explicit构造函数。

double d = 3.9; int i = static_cast<int>(d); // 数值转换，向零截断 Base* pb = static_cast<Base*>(pd); // 向上转换，安全 Derived* pd2 = static_cast<Derived*>(pb); // 向下转换，不做检查，pb 实际不是 Derived 就是 UB void* raw = static_cast<void*>(pd); // 对象指针 -> void*，安全 Derived* pd3 = static_cast<Derived*>(raw); // void* -> 对象指针，必须转回原类型 enum class Color { Red, Green }; int c = static_cast<int>(Color::Red); // 枚举转整型，安全

它明确不能做的事：去掉const、在两个无关的指针类型之间互转、把整数转成指针、把指针转成浮点。这些必须用const_cast或reinterpret_cast。这个"做不到"本身就是价值——编译器帮你在编译期拦住了一大批误用。

static_cast到类类型会走直接初始化，所以explicit构造函数在这里是可用的：

class Tag { public: explicit Tag(int id) : id_(id) {} private: int id_; }; void register_tag(const Tag&); register_tag(42); // 错误 register_tag(Tag{42}); // 可以 register_tag(static_cast<Tag>(42)); // 也可以

一个我踩过的坑：static_cast<Derived*>(pb)在单继承下看起来总是工作正常，因为基类子对象通常就在对象起始位置，地址相同；一旦换成多继承，或者基类不是第一个基类，这个转换的地址计算就会出现偏移，用错了对象布局就会错位。第 5 节会专门讲这个。

4.2 dynamic_cast：唯一会看运行时类型的那个

dynamic_cast是四种转换里唯一依赖运行时类型信息（RTTI）的。它的前提是目标类型是多态类型（至少有一个虚函数）。

class Shape { public: virtual ~Shape() = default; virtual double area() const = 0; }; class Circle : public Shape { /* ... */ }; class Square : public Shape { /* ... */ }; void process(Shape* s) { if (auto* c = dynamic_cast<Circle*>(s)) { // 指针版本失败返回 nullptr，可以放进 if 条件里 } try { auto& sq = dynamic_cast<Square&>(*s); // 引用版本失败抛 std::bad_cast } catch (const std::bad_cast&) { // 处理失败 } }

引用版本会抛异常，指针版本返回空指针，这是两条不同的失败处理路径，选哪个取决于你的代码风格是偏异常还是偏返回值检查。我一般优先用指针版本，因为判断分支写在if里更直观。

dynamic_cast还有一个容易被忽略的能力：交叉转换（cross cast）。在多继承结构中，可以让它把A*直接转到同一个完整对象的兄弟基类B*：

struct A { virtual ~A() = default; }; struct B { virtual ~B() = default; }; struct C : A, B { }; C* pc = new C; A* pa = pc; B* pb = dynamic_cast<B*>(pa); // 交叉转换，运行时查表找到 B 子对象

这种转换用static_cast是做不了的（编译期看不出A*指向的对象是否同时继承自B），只能靠dynamic_cast。代价是每次调用都要走一次运行时类型表查询，在热路径里刷dynamic_cast会带来可测量的性能损耗。我的经验是：如果一段代码里需要用dynamic_cast判断类型，通常说明设计上应该用虚函数或者std::variant来替代，dynamic_cast更多是用在框架的边界、插件加载、消息分发这类无法在编译期确定类型的场合。

另外，很多项目为了减小编译产物体积会开-fno-rtti（MSVC 上是/GR-）。开了之后dynamic_cast直接编译不过，typeid也不能用。如果你的代码要兼容这种配置，就不能把类型识别逻辑建在dynamic_cast上，得改用虚函数返回类型枚举或者访问者模式。

4.3 const_cast 与 reinterpret_cast：只在明确知道后果时使用

const_cast只做一件事：增删const/volatile限定。

void legacy_api(char* s); // 一个没有 const 正确性的老接口 void call_it(const std::string& s) { legacy_api(const_cast<char*>(s.c_str())); // 前提：legacy_api 内部不会真的写 }

关键约束在这里：如果被转换的对象本身是真正 const 的，通过const_cast去掉 const 再去写它，是未定义行为。

const int k = 10; int* p = const_cast<int*>(&k); *p = 20; // 未定义行为，很可能没效果，也可能崩 int n = 10; const int* cp = &n; int* p2 = const_cast<int*>(cp); *p2 = 20; // 这个是合法的，n 本身不是 const 对象

区别就在于原始对象本身有没有 const 限定。编译器的优化器会假设 const 对象不会被修改，把它的值直接内联到使用处，你改了内存也没用。我在评审时看到const_cast会问两个问题：调用的那个接口是不是真的不写？如果写了，能不能改接口签名而不是绕过类型系统？

reinterpret_cast是另外一回事，它不做任何语义转换，只是把同一块比特按另一种类型解释：

std::uintptr_t addr = reinterpret_cast<std::uintptr_t>(ptr); // 指针 -> 整数，需 <cstdint> int* back = reinterpret_cast<int*>(addr); // 整数 -> 指针 char* raw = reinterpret_cast<char*>(&obj); // 按字节访问对象表示，这是允许的

它的风险主要有三个。第一是对齐：把char*转成int*之后解引用，如果地址不是 4 字节对齐，在部分架构上直接硬件异常。第二是严格别名规则：编译器有权假设不同类型指针不会指向同一块内存，通过reinterpret_cast绕过这条规则去读写，优化后可能得到完全错误的结果。第三是函数指针与对象指针之间互转在标准里只是"有条件支持"，不保证在所有平台上工作。

如果你的目标只是"按位的表示做转换"而不是"真的想重新解释指针"，C++20 的std::bit_cast才是正确工具：

#include <bit> float f = 1.0f; auto bits = std::bit_cast<std::uint32_t>(f); // 值语义的位重解释，安全

std::bit_cast要求源和目标都是可平凡复制的、大小相同，编译期就能检查，不涉及指针别名问题。老标准里对应的做法是memcpy到一个同尺寸类型，编译器通常能优化成一条mov指令。

4.4 四种转换的对照与选择顺序

C 风格转换的解析顺序是：先试const_cast，再试static_cast，再试static_cast加const_cast，再试reinterpret_cast，最后试reinterpret_cast加const_cast，第一个能编过的就用。这意味着同一行(T)x在不同上下文里可能是完全不同的操作，而且它可以在你毫不知情的情况下把const去掉。这就是为什么现代 C++ 代码规范基本都禁止使用 C 风格转换，GCC 和 Clang 的-Wold-style-cast就是专门查这个的。

还有一个非常隐蔽的写法是(void)x;，本意是"忽略这个返回值"，但它其实也是一个 C 风格转换。它确实能消掉"未使用"告警，但读代码的人分不清你是想忽略返回值还是想做什么别的。要忽略返回值，用std::ignore = f();或者干脆写(void)并在旁边加注释说明意图。

5. 指针与类层次：地址偏移发生在你看不见的地方

5.1 派生类指针到基类指针不是"同一个地址"

很多人下意识认为Base* pb = pd;只是把地址复制过去，值是同一个。在单继承且基类是对象起始位置的情况下确实如此，但这是实现细节，不是标准保证。

标准保证的是：Base*指向的是完整对象中Base 子对象的地址。如果存在多继承，编译器会在转换时插入一个偏移量调整。用代码验证一下：

#include <cstdint> #include <iostream> struct A { virtual ~A() = default; int a = 1; }; struct B { virtual ~B() = default; int b = 2; }; struct C : A, B { int c = 3; }; int main() { C* pc = new C; A* pa = pc; B* pb = pc; std::cout << "C* = " << static_cast<void*>(pc) << "\n"; std::cout << "A* = " << static_cast<void*>(pa) << "\n"; std::cout << "B* = " << static_cast<void*>(pb) << "\n"; // 和前面不一样 }

在典型的 Itanium ABI 实现上，A*和C*地址相同（A 是第一个基类），B*则比C*大一个偏移量（通常是 8 或 16 字节，取决于 vptr 和填充）。也就是说，pb = pc这一行赋值，编译器在背后生成了一条加法指令。而reinterpret_cast<B*>(pc)只会把同样的数值原封不动地当成B*用，得到的是错误地址，解引用pb->b读到的其实是 A 子对象或者虚表指针的内容。

这个差异在向下转换时同样存在。static_cast<C*>(pb)会正确地减掉偏移量，只要pb真的指向一个C对象的B子对象，结果就是正确的C*。但如果不检查实际类型就转，拿到的是一个基于错误假设的指针，用它访问成员就是未定义行为。

5.2 多继承与虚继承下的转换限制

有一条规则很反直觉但必须记住：从虚基类向下转换，不能用static_cast。

struct Base { virtual ~Base() = default; }; struct Left : virtual Base { }; struct Right : virtual Base { }; struct Diamond : Left, Right { }; Diamond d; Base* pb = &d; // 隐式向上转换，没问题 // Diamond* pd = static_cast<Diamond*>(pb); // 编译错误 Diamond* pd = dynamic_cast<Diamond*>(pb); // 必须用 dynamic_cast

原因是虚基类在完整对象中的位置在编译期无法确定——可能有多个派生路径共享同一个 Base 子对象，偏移量取决于实际的继承结构。编译器只能把这件事推到运行时，交给 RTTI 处理。

虚继承配合dynamic_cast有一点开销，但在框架设计中它的价值很大。我在做插件系统的时候，用的就是"一个虚基类接口 +dynamic_cast判断插件是否实现了某个可选接口"的模式，这样新增可选能力不需要改接口基类。

另一个常见需求是指针身份比较。两个Base*指向同一个对象的不同子对象时，直接比较指针是不相等的。这时候用dynamic_cast<void*>拿到最派生对象的地址再比：

bool same_object(Base* x, Base* y) { return dynamic_cast<void*>(x) == dynamic_cast<void*>(y); }

这个技巧只在多态类型上用，并且要求两个指针都非空，否则会把两个空指针判成"同一个对象"。

5.3 void* 往返与函数指针的边界

void*在 C++ 里是"无类型指针"，很多 C 接口用它做通用参数。往 C++ 里搬的时候要注意一个差异：C 允许void*隐式转成任意对象指针，C++ 不允许。

/* C 代码 */ int* p = malloc(sizeof(int) * 10); // C 里能编过

// C++ 代码 int* p = static_cast<int*>(std::malloc(sizeof(int) * 10)); // C++ 必须显式转

标准保证T*转void*再转回T*能得到原值，但不保证转成别的类型再转回来是正确的。所以void*只适合做"过路传递"，回来的那一刻必须转成原来那个类型。

函数指针的情况更微妙。C++ 标准把函数指针和对象指针之间的转换列为"有条件支持"，也就是说不是所有平台都保证能工作。reinterpret_cast能编过，但结果能不能调用、能不能转回来，取决于具体实现。我处理函数指针时坚持两条：一是函数指针只在函数指针之间转（用reinterpret_cast保留原始类型信息，不超过一次中间转换），二是绝不用void*当中转。如果确实需要在一张统一的表里存不同类型的函数指针，用std::variant或者模板包装器，别用裸void*。

另外，C++17 引入了std::byte，专门用来表示"原始字节"这个语义。以前大家用unsigned char或者char做字节缓冲区，问题是char的符号性还有平台差异。std::byte只能参与位运算和比较，不能参与算术，从语言层面就把"这个不是字符"这件事表达清楚了。涉及reinterpret_cast<std::byte*>的地方，比reinterpret_cast<char*>更不容易被误用。

6. 落地清单：我在项目里怎么管住类型转换

6.1 编译期把关：先把告警打开再说

隐式转换的坑，能在编译期抓到的绝对不要留到运行期。GCC 和 Clang 上有几个关键选项：

# CMake 里给目标加编译选项 target_compile_options(my_target PRIVATE -Wall -Wextra -Wconversion # 报告可能改变值的隐式转换 -Wsign-conversion # 专门报告符号相关的隐式转换 -Wold-style-cast # 报告 C 风格转换 -Wfloat-equal # 报告浮点数的 == 比较 -Werror=conversion # 在 CI 里把它当错误卡住 )

MSVC 上对应的做法是/W4 /permissive-，GCC 风格告警里没有直接对应的/Wconversion，需要靠/W4里的 C4244（转换可能丢失数据）、C4267（size_t转int）这些编号来覆盖。MSVC 的/Wall会开启一堆和第三方头文件冲突的告警，一般不用，/W4加#pragma warning精确控制更实际。

-Wconversion在存量代码上打开会炸出一大堆告警，这是正常的。我的做法是先在新模块上开启，老模块按目录逐步灰度，用-Wno-conversion或者 CMake 的set_source_files_properties逐个文件排除，配合一个"新增文件必须零告警"的评审规则。直接全项目打开然后所有人无视告警，比不开还糟糕，因为真正的风险会被淹没在噪声里。

另一个几乎零成本的防护是用大括号初始化。{}初始化会阻止窄化转换，编译期直接报错：

int a = 3.9; // 能编过，a 是 3，静默丢失 int b{3.9}; // 编译错误，好事 char c = 300; // 能编过，实现定义 char d{300}; // 编译错误 int e{2.0}; // 能编过：字面量恰好是整数且能原样换算回去，标准允许 int f{2.5}; // 编译错误

代价是auto x{1};在 C++17 之前推导成std::initializer_list<int>而不是int（C++17 修正了这个问题）。所以我会写auto x = 1;，只在需要防护窄化的地方用大括号。

6.2 两个可以直接抄过来的转换工具

大整数转小整数，我封装过下面这个模板，思路是"先判范围，再转换"：

#include <limits> #include <stdexcept> #include <type_traits> // C++20 直接用 std::in_range，这里给 C++17 的等价实现 template <typename To, typename From> constexpr bool in_range_for(From v) noexcept { static_assert(std::is_integral_v<To> && std::is_integral_v<From>); if constexpr (std::is_signed_v<From> == std::is_signed_v<To>) { // 符号性相同，比较值域上下界即可（注意先把 From 转成公共类型比较） return v >= static_cast<From>(std::numeric_limits<To>::min()) && v <= static_cast<From>(std::numeric_limits<To>::max()); } else if constexpr (std::is_signed_v<From>) { // From 有符号，To 无符号：负数一律不合格 return v >= 0 && static_cast<std::make_unsigned_t<From>>(v) <= std::numeric_limits<To>::max(); } else { // From 无符号，To 有符号：先判断能否被 To 的 max 覆盖 using UTo = std::make_unsigned_t<To>; return v <= static_cast<UTo>(std::numeric_limits<To>::max()); } } template <typename To, typename From> constexpr To narrow_cast(From v) { if (!in_range_for<To>(v)) { throw std::range_error("narrow_cast: value out of range"); } return static_cast<To>(v); }

注意里面那几个static_cast不能省。std::numeric_limits<To>::max()返回的是To类型，直接和From比较会触发隐式转换——而我们要处理的恰恰就是隐式转换出问题的场景，用static_cast把类型对齐之后再比，语义才明确。这段代码在带-Wconversion的编译下应该是零告警的，可以自己验证一下。

第二个工具是安全比较，C++20 有标准实现，老版本可以照下面写：

template <typename T, typename U> constexpr bool safe_less(T a, U b) noexcept { static_assert(std::is_integral_v<T> && std::is_integral_v<U>); if constexpr (std::is_signed_v<T> == std::is_signed_v<U>) { return a < b; // 符号相同，直接比 } else if constexpr (std::is_signed_v<T>) { // a 有符号，b 无符号：a 为负则必然小于 b return a < 0 || static_cast<std::make_unsigned_t<T>>(a) < b; } else { // a 无符号，b 有符号：b 为负则必然大于 a return b > 0 && a < static_cast<std::make_unsigned_t<U>>(b); } }

有 C++20 就直接用std::cmp_less、std::cmp_greater、std::in_range，标准库实现经过充分测试，还能在编译期求值。我把它写出来主要是为了应对大量还在 C++14/17 的存量项目——这类项目才是绝大多数公司的现实。

提示：这两个模板都标了constexpr，在有 C++20std::is_constant_evaluated的环境里可以在编译期做范围校验，把运行时错误提前到编译期。如果模板参数是常量表达式，narrow_cast<int>(1000000LL)这类调用能直接编译失败，效果比运行时抛异常好得多。

6.3 代码评审时我会盯的几个位置

规则写在文档里没人记得住，我把它压成了一张"看到就要停下来看两眼"的位置清单，贴在团队 wiki 上：

• 函数签名里出现size_t或unsigned，调用方却用int接收。这类问题十有八九会变成"大值变小值"或者"负数变巨大正数"。
• 循环变量和container.size()比较。要么都用size_t，要么用std::ssize，混用必出问题。
• 每一处reinterpret_cast旁边必须有一行注释，说明为什么这个转换是安全的，以及类型为什么必须这么转。没有注释的直接打回。
• const_cast的调用点，要确认被调用函数真的不写，并且问一句"能不能改接口签名而不是绕过"。
• 所有单参构造函数，没加explicit的要能说清楚为什么应该保留隐式转换。说不清楚就加。
• 金额、时间戳、ID 这类高精度语义字段，绝对不能用double或float存。金额用整数分，时间用int64纳秒或std::chrono类型。
• 浮点字面量后缀。3.14是double，3.14f是float，把double赋给float变量在-Wconversion下会报警。我个人习惯是浮点字面量一律带后缀，看到裸的3.14会问一句是不是故意的。
• 0、NULL、nullptr的混用。新代码一律nullptr，NULL在有些实现里是0，会参与整型重载决议，f(NULL)调用f(int)而不是f(void*)这种事故是真实存在的。

还有一个我自己的习惯：在头文件里，所有接受自定义类型的函数参数，我会刻意用const T&而不是T或者T&&之外的形式，目的是减少隐式构造临时对象的机会。临时对象在函数调用期间存活，如果函数内部把它存下来（比如存了个引用或者指针），出了作用域就是悬垂引用。这类 bug 在std::string_view、std::span上尤其常见——它们本身是轻量视图，从临时字符串构造出来的视图生命周期只到表达式结束。隐式转换在这里的杀伤力比在数值类型上大得多。

再分享一个调试技巧。当你不确定某个表达式到底触发了哪次隐式转换时，最直接的办法是把中间结果打印出来，用static_assert或decltype查类型：

auto x = a + b; static_assert(std::is_same_v<decltype(x), unsigned long long>, "类型和预期不符"); std::cout << typeid(decltype(x)).name() << "\n";

typeid(...).name()在不同编译器上输出的名字格式不同，GCC 和 Clang 可以用c++filt还原成可读形式。这比盯着代码猜快得多。

我个人在实际操作中的体会是，类型转换这件事，真正需要记的规则没几条：整型运算先做提升再做算术转换、窄化会截断、浮点转整型向零取整且越界是 UB、用户定义转换最多一次、explicit是默认应该加的东西、C 风格转换能不用就不用。剩下的全部可以交给编译器告警和几个小工具函数去兜。真正容易出事的不是规则本身，而是"我以为我记住了"。