函数重载、名字空间、强类型枚举与别名

本节目标

掌握 C++23 的函数重载、名字空间、强类型枚举和 using 类型别名的接口边界。

函数签名、名字空间、枚举和类型别名共同构成接口的可读边界：调用者能看见哪些名字、哪些实参形状有效，以及一个状态值是否能被误当成整数。先让类型和作用域表达意图，再考虑复用写法。

重载集与函数签名

一组同名函数要成为可用的重载，声明必须让编译器能从参数类型列表等签名要素区分候选。暂时省略与重载区分无关的属性和 constexpr 说明符，代表程序中的两个声明具有下面的形状：

std::string_view describe(int);
std::string_view describe(double);

调用者传入 int 或 double，都是在请求同一种“描述类型”的操作。相反，只把第一个声明的返回类型改成 int，参数列表仍是 (int)，不会产生另一个可选重载；返回类型单独不同不能形成重载。

因此，设计重载集时既要保证参数形状可区分，也要保证各候选表达一致含义。若只是为了省去一个名字而把不相干操作塞进同一个重载集，使用不同函数名通常更清楚。

重载决议与转换序列

调用发生后，编译器先从可见候选中留下可行函数，再比较每个实参所需的隐式转换序列。对本章涉及的标准转换，可以先按下面的层次判断：

转换等级或结果	例子	对选择的影响
精确匹配	`int` 实参交给 `describe(int)`	在其他条件相当时，优于需要提升或其他标准转换的候选
提升	`short` 提升为 `int`	优于一般标准转换，但不优于精确匹配
其他标准转换	`int` 转为 `double`	候选仍可能可行，但转换等级低于提升
无唯一最佳候选	`choose(long)` 与 `choose(double)` 同时接收 `int`	两边都只得到转换等级，且没有其他规则分出高下时，调用二义

代表程序的 describe(values[0]) 中，values[0] 是 int，所以 describe(int) 得到精确匹配并胜过 describe(double) 所需的转换。不能因为候选不止一个，就猜测编译器会“自动挑一个差不多的”；只有规则能选出唯一最佳可行函数，调用才成立。

用户定义转换、模板候选和初始化列表还会增加规则层次。本章只建立候选、转换等级与二义性的边界，复杂模板决议留给模板专题。

默认实参

默认值属于调用接口，而不是函数体在运行时查询的一项配置。把它放在调用者能看见的一处声明中即可：

void log(int level = 1);

void report() {
  log();  // 当前调用点看见默认实参，因此等价于传入 1
  log(3); // 显式实参不使用默认值
}

默认实参在调用点按当时可见的声明绑定，而不是在函数定义处动态取得。换句话说，调用点从可达声明取得默认实参；若不同调用点看见的声明集合不同，它们能使用的默认值也可能不同。不要在不同头文件里重复或改变同一参数的默认实参，应把默认值保留在单一、公开的接口声明中。

默认表达式还要分开判断名字绑定与求值时机：名字在默认实参出现处查找，而表达式在每次省略实参的调用中求值。例如默认值若写成 nextLevel()，每次 log() 都会重新调用它，而 log(3) 不会求值该表达式。因此，修改库的默认值可能要求调用方重新编译；已经编译的调用点不会因为只链接到新实现而改用新值。

inline 与单一定义规则

inline 的语言合同与优化器是否展开一次函数调用，是两个独立问题。像 inline constexpr int limit{23}; 这样的定义可以放进被多个源文件包含的头文件，让满足条件的同一实体在多个翻译单元中出现；它并没有取消单一定义规则。

反过来，inline 不等于强制内联；优化器可以不展开带有 inline 的调用，也可以展开没有这个说明符的调用。因此既不能把它当成性能承诺，也不能因为写了 inline 就放任各翻译单元看到不同定义。

同一内联实体采用 ODR 允许的多定义形式时，各定义至少要具有相同 token sequence；除标准列出的例外外，对应名称查找必须指向相同实体等，不只语义等价。仅让定义具有相同名称，或手工写成“看起来效果一样”，都不足以满足这份合同。

名字空间与名称查找

名字空间为库接口划出可命名的边界，限定查找和未限定查找则决定某次使用会找到哪些声明。下面的代表程序中，interface_contract::namespace_value 使用限定名直接指定目标；describe(values[0]) 是未限定函数调用，普通查找找到了全局作用域的重载集。

interface_report.cpp
#include <array>
#include <iostream>
#include <string_view>

namespace interface_contract {
inline constexpr int namespace_value{23};
}

enum class State { ready };

using Values = std::array<int, 3>;

[[nodiscard]] constexpr std::string_view describe(int) { return "int"; }

[[nodiscard]] constexpr std::string_view describe(double) { return "double"; }

[[nodiscard]] constexpr std::string_view stateName(State state) {
  return state == State::ready ? "ready" : "unknown";
}

int main() {
  const Values values{4, 8, 15};
  const State state{State::ready};
  const std::string_view interfaceStatus{"stable"};

  static_assert(describe(1.5) == "double");

  std::cout << "overload=" << describe(values[0]) << '\n';
  std::cout << "namespace_value=" << interface_contract::namespace_value << '\n';
  std::cout << "enum_state=" << stateName(state) << '\n';
  std::cout << "alias_size=" << values.size() << '\n';
  std::cout << "interface=" << interfaceStatus << '\n';
}

输出：

overload=int
namespace_value=23
enum_state=ready
alias_size=3
interface=stable

普通未限定查找从当前作用域逐层向外；一旦当前作用域找到声明，不继续搜索父作用域。因此，内层同名声明可能隐藏外层重载，读者也不应只凭名字拼写推断来源。在较大作用域依赖某个同名未限定查找“恰好成功”，会让接口来源随周围声明而变化；限定名把意图写得更稳定。

模板与 ADL 只作边界预览：ADL 只适用于未限定函数调用，并可能把实参类型的关联名字空间中的函数加入候选集；命中成员、块作用域函数或非函数声明时，ADL 被抑制。只有普通查找没有触发这些抑制条件时，才继续考虑关联候选；不需要为使用 ADL 而在头文件中开放整个名字空间。

using 声明与 using 指令

两种 using 形式改变查找集合的范围不同：

using std::string_view; // using 声明：引入指定名称
using namespace std;    // using 指令：让该名字空间的成员参与未限定查找

using std::string_view; 只在当前作用域引入指定的名字，边界容易审查；using namespace std; 不等同于引入一个类型，它会让更广的一组名字参与后续未限定查找，更容易与当前或未来声明冲突。

头文件中禁止全局 using namespace，因为影响会传播给每个包含者。在实现文件的小作用域内也应优先写限定名，或只为反复使用的单个名字添加 using 声明。

enum class 与底层类型

作用域枚举把枚举项留在枚举类型内部，并阻止枚举值到整数的隐式转换：

enum class State { ready };
State state{State::ready};
// int raw = state; // 拒绝：State 不会隐式转换为 int

无作用域枚举的枚举项会进入外围作用域，并可参与到整数类型的隐式转换；若直接写成 enum State { ready };，ready 就不再受 State:: 限定。enum class 的 State::ready 写法既限制名称泄漏，也让状态参数不容易被普通整数替代。

协议或存储格式要求明确的表示范围时，可以写 enum class State : std::uint8_t 指定底层类型；这仍不替代对合法值域、编码顺序和序列化规则的验证。

类型别名与别名模板

别名声明可以给复杂类型一个面向接口的名字，别名模板则把这项命名扩展到一族类型：

using Values = std::array<int, 3>;
template<class T> using Buffer = std::vector<T>;

Values 仍是 std::array<int, 3> 本身，代表程序可以直接从对象调用 size() 得到 3；Buffer<int> 也仍是对应的 std::vector<int>。别名不会创建新类型，也不会改变原类型的转换、所有权或复杂度规则。

若接口必须把两种语义相同表示的值区分开，应设计真正的包装类型及其转换接口，而不能把别名当作阻止它与原类型互用的强类型包装。

头文件接口与链接边界

头文件会分别成为每个包含它的翻译单元的一部分。接口声明可以重复出现，定义能否随头文件复制则要同时判断实体类别、链接和 ODR：

内容	头文件	单个 `.cpp`	原因
供多个翻译单元调用的函数声明	放置 `void render(const Values& values);`	实现文件包含同一头文件	声明让每个调用点按同一函数类型接受检查
普通外部链接函数或对象定义	只保留声明	放置唯一普通定义	若把定义写进公共头文件，每个包含者都会复制它并违反定义责任
`inline` 函数或变量定义	可以放置同一份定义	不依赖一个普通外部定义	每个使用它的翻译单元都能看到定义，同时仍须满足 inline 的 ODR 条件
仅供实现使用的辅助名字	不进入公共接口	留在实现文件并限制可见边界	防止调用方依赖私有细节，也减少名称与链接冲突

因此，普通非内联外部定义通常只应出现在一个实现文件；需要放入头文件的函数或变量定义必须满足相应的链接与 ODR 规则。include guard 只能防止同一翻译单元重复处理头文件，不能把跨翻译单元的多个普通定义合并成一个。

头文件还应直接包含其公开声明所需的依赖，不依靠包含顺序偶然带来的间接包含；对应 .cpp 先包含自己的头文件，能让定义与公开声明的不一致尽早暴露。

常见陷阱

接口问题通常来自候选、可见声明和定义责任被分散到不同位置。可以按症状逐项排查：

两个重载都需要同等级转换，且没有规则产生唯一最佳候选时，调用会二义。应缩小候选集、明确转换，或为不同语义改用不同函数名。
同一参数的默认实参散落在多个声明中，会让不同调用点依赖各自可见的接口。默认值应集中在单一公开声明，并在修改后重新编译受影响的调用方。
全局 using 指令会扩大未限定查找范围；尤其不要从公共头文件把这项影响传播给包含者，应优先使用限定名或单个 using 声明。
普通外部定义被头文件复制，或 inline 定义在不同翻译单元中不满足 ODR 条件，都会造成 ODR 违规。相同拼写不是一致定义的充分证明。
State state{State::ready}; 明确用具名枚举项初始化当前状态；若改用整数标志与隐式转换传递状态，再靠注释约定含义，类型系统就无法维持这条边界。

接口演进时，先检查调用点可见声明和名称查找范围，再核对每个翻译单元看到的定义是否一致；当头文件接口变大时，声明、定义和名字空间边界仍应能够独立审查。

本节目标

重载集与函数签名​

重载决议与转换序列​

默认实参​

inline 与单一定义规则​

名字空间与名称查找​

using 声明与 using 指令​

enum class 与底层类型​

类型别名与别名模板​

头文件接口与链接边界​

常见陷阱​