IDE编辑器

IDE 中的代码编辑器通常会在你将鼠标指针悬停至某个程序实体，如变量、形参、函数等时，显示出该实体的类型。例如：

1
2
3
4

const int theAnswer = 42;

auto x = theAnswer;
auto y = &theAnswer;

IDE 编辑器很可能会显示出，x 的类型推导结果是 int, 而 y 则是 const int*。

但是如果遇到较为复杂的类型，IDE显示的信息就不太有用了。

编译器诊断信息

一条有效途径是使用该类型导致某些编译错误。而报告错误的消息几乎肯定会提及导致该错误的类型。

例如：

1
2

template<typename T> //只声明TD而不定义
class TD; // TD是“类型显示类”的缩写

只要试图具现该模板，就会诱发一个错误信息，原因是找不到具现模板所需要的定义。

运行时输出

使用 printf来显示类型信息，这种方法只有到了运行期才能使用，却可以对类型输出的格式提供完全的控制。

1
2

std::cout << typeid(x).name() << '\n'; //display types for x and y
std::cout << typeid(y).name() << '\n'; 

但是推导结果并不可靠，根据C++标准，std::type_info::name处理类型的方式类似于按值传递参数，这意味着它会忽略掉引用和顶层的const/volatile修饰符。

推荐方案：使用 Boost.TypeIndex库
例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#include <boost/type_index.hpp>

template<typename T>
void f(const T& param)
{
    using std::cout;
    using boost::typeindex::type_id_with_cvr;

    //显示T
    cout << "T =     "
         << type_id_with_cvr<T>().pretty_name()
         << '\n';
    
    //显示param类型
    cout << "param = "
         << type_id_with_cvr<decltype(param)>().pretty_name()
         << '\n';
}

它提供的type_id_with_cvr()函数会保留类型的const、volatile和引用修饰符。其成员函数pretty_name产生一个包含人类可读的类型表示的std::string。

总结

• 利用 IDE 编辑器、编译器错误消息和 Boost.Typelndex 库常常能够查看到推导而得的类型。
• 有些工具产生的结果可能会无用，或者不准确。所以，理解 C+＋类型推导规则是必要的。

auto与代理类的问题

当使用auto进行类型推导时，如果表达式返回的是代理类，auto会推导出代理类型而不是被代理的实际类型，可能导致未定义行为。

例如：

1
2
3

std::vector<bool> features(const Widget& w);
bool highPriority = features(w)[5];  // 含义是w具有高优先级吗？
processWidget(w, highPriority);      // 按照w的优先级来处理

这段代码没有什么问题，但是如果把highPriority从显式类型改成auto：

1
2

auto highPriority = features(w)[5];  // 危险！推导出std::vector<bool>::reference
processWidget(w, highPriority);      // 可能产生未定义行为！

原因：

1. std::vector<bool>内部使用紧凑结构存储（每个bool占1位）
2. 内存最小寻址单位是字节，单个 “位” 没有独立的内存地址；
3. operator[]无法返回bool&（不能对单个位取引用），因此返回一个代理类std::vector<bool>::reference
4. auto不会自动把代理类转换成bool，而是直接推导成std::vector<bool>::reference类型。

因此需要显式声明其为bool类型：

1

auto highPriority = static_cast<bool>(features(w)[5]);  // 安全！

如何识别出代理类

头函数或函数签名会反映出其存在：

1
2
3
4
5
6
7
8
9

namespace std {
    template<class Allocator>
    class vector<bool, Allocator> {
    public:
        class reference { ... };  // 代理类！
        reference operator[](size_type n);
        ...
    };
}

非同寻常的返回值类型：如：std::vector<T>::operator[]通常返回T&，如果返回类型不是T&，可能是代理类。

常见的代理类场景：

• std::vector<bool>的相关操作：位无独立地址，无法返回引用。
• 表达式模板（用于优化数值计算）：临时对象多，计算效率低。
• 某些智能指针的实现：内存访问不安全/权限难控。
• 延迟求值（lazy evaluation）系统：提前计算可能无效。

其他应用场景

1. 精度控制

1
2

double calcEpsilon();
auto ep = static_cast<float>(calcEpsilon());  // 明确表示精度降低

还可以应用于计算随机访问迭代器的容器中的某个元素下标。

2. 类型转换强调

1
2
3

double d = 0.7;
size_t size = 100;
auto index = static_cast<int>(d * size);  // 明确表示浮点到整数的转换

3. 表达式模板的代理

1
2

Matrix m1, m2, m3, m4;
auto sum = static_cast<Matrix>(m1 + m2 + m3 + m4);  // 避免代理类型

总结

• “隐形”的代理类型可以导致auto根据初始化表达式推导出“错误的”类型。
• 带显式类型的初始化习惯用法强制auto推导出你想要的类型。

1. 忘记初始化产生未知行为

但是，auto声明的变量其类型推导自其初始化表达式，所以它们必须初始化：

1
2
3

int x1; // 有潜在的未初始化风险 
auto x2; // 编译错误！必须有初始化表达式
auto x3 = 0; // 没问题， x 已经定义了

2. 类型冗长复杂，难以直接写出

在泛型编程、容器操作等场景中，尝尝会出现冗长复杂的类型声明。如：typename std::iterator_traits<It>::value_type，可以直接使用auto代替。

1
2
3
4
5

// 传统显式声明：冗长繁琐，易出错 typename 
std::vector<int>::const_iterator it1 = vec.cbegin(); 

// auto 声明：简洁高效，无需记忆复杂类型 
auto it2 = vec.cbegin();

3. 类型不匹配导致意外的类型转换

std::function是C++11标准库中的一个模板，它把函数指针的思想加以推广。函数指针只能指向函数，而std::function却可以指向任何可调用对象，即任何可以像函数一样实施调用之物。可以处理C++中的闭包类型。

但是，闭包类型只有编译器自己知道，显式声明闭包类型可能产生潜在的类型转换。如：

1
2
3
4
5
6

std::unordered_map<std::string, int> m; 

// 看似合理，实则存在类型不匹配
for (const std::pair<std::string, int>& p: m) {
 ... // 在p上实施某些操作
}

哈希表中的 std::pair （也就是 std::unordered_map 本身）的类型并不是 std::pair<std::string, int> ，而是 std:: pair<const std::string, int>。

还可以避免一种被称作者为“类型捷径”的问题。如：

1
2

std::vector<int> v; 
unsigned sz = v.size();

在 32 位 Windows 上， unsigned 和 std:: vector<int>::size_type 的尺寸是一样的，但在 64 位 Windows 上， unsigned 是 32 位，而 std:: vector<int>::size_type 则是 64 位。

其他优势

• auto存储所需的内存可能比std::function更小，且调用效率更高（std::function采用类型擦除技术，存在间接调用开销，auto直接推导闭包原始类型，无额外损耗）。
• 方便进行统一修改和重构，变量类型会随初始化表达式自动适配，修改源头类型时，无需手动调整所有相关变量，减少遗漏风险。
• 支持匿名类型的直接使用，C++中的lambda表达式、匿名类均为编译器生成的匿名类型，无法手动显式声明，auto是唯一能直接存储这类对象的方式。

可能存在的问题：无法一眼看出对象的类型，但是IDE的对象类型显示能力能缓和这个问题，而且良好的命名比类型更能表达意图。

总结

• auto变量必须初始化，基本上对会导致兼容性和效率问题的类型不匹配现象免疫，还可以简化重构流程，通常也比显式指定类型要少打一些字。
• auto类型的变量都有着2和6中所描述的毛病。

1. 轻量高效：默认删除器下，大小和原始指针一致，操作（如解引用）的执行效率和原始指针几乎无差别，可用于内存 / 性能敏感场景。
2. 独占所有权：一个非空的 std::unique_ptr 独占指向的资源，仅可移动（move-only）、不可拷贝—— 拷贝会导致两个指针同时管理同一资源，析构时重复销毁；移动则会将所有权从源指针转移到目标指针（源指针置空）。
3. 自动析构：析构时会自动销毁指向的资源（默认调用 delete），即便程序因异常、提前返回等非典型流程终止（除异常传播到 main 外、调用abort/exit等极端情况），也能保证资源释放，避免内存泄漏。

应用场景

1. 工厂函数返回值：

   适合作为继承体系对象的工厂函数返回类型（如 Investment 基类 + Stock/Bond 派生类），调用方独占工厂创建的堆对象所有权，无需手动管理销毁，示例中通过makeInvestment返回unique_ptr<Investment>，自动释放派生类对象。

2. 接管 C 风格 API 的堆数组：

   std::unique_ptr 有数组版本 std::unique_ptr<T[]>（仅适配 C 风格堆数组），但优先推荐std::array/std::vector等容器，仅在必须接管原始数组时使用。

自定义删除器

1. 使用方式：可自定义销毁逻辑（如先打日志再delete），删除器可以是 lambda、函数对象或普通函数，需将删除器类型作为std::unique_ptr的第二个模板参数。

2. 注意事项：

   • 管理继承体系对象时，基类必须声明虚析构函数，否则通过基类指针删除派生类对象会未定义行为；
   • 删除器影响unique_ptr大小：无状态 lambda（不捕获变量）无额外开销，函数指针 / 有状态删除器会增加其大小（通常从 1 个指针大小变为 2 个），优先用 lambda 实现自定义删除器。

3. C++14 优化：支持函数返回类型推导，可将删除器定义在工厂函数内部，代码更简洁封装。

特殊形式与兼容性

1. 两种形式区分：

   • std::unique_ptr<T>：管理单个对象，支持*/->解引用；
   • std::unique_ptr<T[]>：管理数组，支持[]下标访问；

2. 无缝转换为std::shared_ptr：

   std::unique_ptr 可直接赋值给std::shared_ptr，工厂函数返回unique_ptr既保证调用方的高效独占使用，也不限制调用方转为共享所有权（shared_ptr），是工厂函数返回类型的最优选择。

总结

1. std::unique_ptr 是轻量、高效的 “独占所有权” 智能指针，仅可移动，析构自动释放资源；
2. 自定义删除器灵活，但无状态 lambda 开销最小，管理继承对象需基类虚析构；
3. 核心优势是适配工厂函数场景，且可无缝转为std::shared_ptr，兼顾独占 / 共享所有权需求。

1. 功能：管理共享所有权的资源，兼具 “自动垃圾回收”（无需手动管理生命周期）和 “销毁可预测”（最后一个指向资源的 shared_ptr 销毁时，资源确定销毁）的优势，比纯垃圾回收语言的资源管理更通用、销毁时机更可控。

2. 实现基础：引用计数（跟踪指向资源的 shared_ptr 数量）：

   • 拷贝 / 构造：递增引用计数；
   • 析构 / 赋值指向其他对象：递减引用计数；计数归 0 时销毁资源；
   • 移动更高效：移动 shared_ptr 无需修改引用计数（源指针置空），比拷贝快。

3. 性能开销（对比原始指针 /unique_ptr）：

   • 大小：原始指针的 2 倍（存储 “指向资源的指针”+“指向引用计数的指针”）；
   • 额外成本：引用计数需动态分配（make_shared 可优化）、引用计数修改是原子操作（线程安全但比非原子操作慢）。

自定义删除器

差异：删除器类型不是 shared_ptr 类型的一部分（unique_ptr 的删除器是类型一部分）；

• 优势：不同删除器的同类型 shared_ptr（如 shared_ptr<Widget>）可放入同一容器、相互赋值、传入同一函数；
• 大小不变：删除器存储在 “控制块” 中，而非 shared_ptr 对象本身，因此无论删除器是何类型，shared_ptr 始终是 2 个指针大小。

控制块

1. 定义：每个被 shared_ptr 管理的资源对应一个控制块，除引用计数外，还存储自定义删除器 / 分配器等；

2. 创建规则（错用会导致未定义行为）：

   • make_shared、从 unique_ptr/ 原始指针构造：创建新控制块；
   • 从 shared_ptr/weak_ptr 构造：复用已有控制块（不新建）；

3. 致命风险：从同一原始指针创建多个 shared_ptr → 生成多个控制块 → 资源被多次销毁；

   • 规避：① 直接传 new 的结果给 shared_ptr 构造函数（而非原始指针变量）；② 用已有 shared_ptr 拷贝构造新对象（复用控制块）。

this 指针的安全使用（enable_shared_from_this）

1. 问题：成员函数中直接传 this（原始指针）给 shared_ptr → 可能为同一对象创建新控制块（若外部已有指向该对象的 shared_ptr）；
2. 解决方案：让类继承 std::enable_shared_from_this<类名>（CRTP 模式），调用 shared_from_this() 替代 this（复用已有控制块）；
3. 前提：调用 shared_from_this() 前，已有指向该对象的 shared_ptr（否则行为未定义）；最佳实践是类的构造函数私有化，通过工厂函数创建 shared_ptr 对象。

局限性与选型建议

1. 不支持数组（C++17 前）：API 为单个对象设计（无 operator[]），强行管理数组是糟糕设计，优先用 std::array/vector；
2. 所有权不可变更：一旦资源由 shared_ptr 管理，即使引用计数为 1，也无法转为 unique_ptr；
3. 选型原则：能独占则优先用 unique_ptr（更高效），unique_ptr 可无缝转为 shared_ptr；仅确需共享所有权时，才用 shared_ptr。

总结

1. std::shared_ptr 是共享所有权资源的 “自动垃圾回收” 方案，核心靠引用计数 + 控制块实现，但有大小、原子操作等性能开销；
2. 自定义删除器不影响 shared_ptr 类型，这是其比 unique_ptr 灵活的关键，但删除器存储在控制块中；
3. 避坑点：禁止从同一原始指针创建多个 shared_ptr，成员函数中用 shared_from_this() 替代直接传 this；
4. 优先用 unique_ptr 管理独占资源，仅共享时用 shared_ptr。

通用规则：如果在一对大括号里声明一个名字，则该名字的可见性限定在括号括起来的作用域内。

但这个规则不适用于 C++98 风格的枚举类型中定义的枚举变量：枚举变量的属于包含着这个枚举类型的作用域，此作用域内不能有其他实体取相同的名字。

1
2

enum Color { black, white, red }; //black, white, red在Color所在的作用域
auto white = false; //错误! white早已在这个作用域中声明

枚举量的名字泄露到枚举类型所在作用域的现象被称为：不限范围的枚举类型（未限域 enum）。

在 C++11 中，限定作用域的枚举类型（枚举类 / 限域 enum）不会以这样的方式泄露名字：

1
2
3
4
5
6

enum class Color { black, white, red }; //black, white, red限制在Color域内
auto white = false; //没问题，域内没有其他“white”

Color c = white; //错误，域中没有枚举名叫white
Color c = Color::white; //没问题
auto c = Color::white; //也没问题（也符合Item5的建议）

限域枚举的枚举量是强类型的

强类型：语言会对类型兼容性做严格检查，禁止隐式的、不安全的类型转换，每个值都有明确且固定的类型，类型错误会被尽可能早地捕获（编译器 / 运行期）。

不限域枚举类型的枚举量可以隐式转换为整数类型（并能够从此处进一步转换到浮点类型），导致语义扭曲的代码合法：

1
2
3
4
5
6
7
8
9

enum Color { black, white, red }; //未限域enum

std::vector<std::size_t>primeFactors(std::size_t x); //func返回x的质因子

Color c = red;
if (c < 14.5) { // Color与double比较 (!)
    auto factors = primeFactors(c); // 向std::size_t参数传递Color (!)
    …
}

从限定作用域的枚举类型到任何其他类型都不存在隐式转换路径，类型安全更优：

1
2
3
4
5
6
7
8
9
10
11

enum class Color { black, white, red }; //Color现在是限域enum

Color c = Color::red;                   
if (c < 14.5) {                         //错误！不能比较Color和double
    auto factors = primeFactors(c);     //错误！不能向std::size_t参数传Color
    …
}
// 仅显式强制转换才允许（可控的类型转换）
if (static_cast<double>(c) < 14.5) {
    auto factors = primeFactors(static_cast<std::size_t>(c));
}

限定作用域的枚举类型可以进行前置声明

前置声明的核心前提是编译器能确定枚举的底层类型（内存大小）：

1
2

enum Color; // 错误！未限域enum无默认底层类型，编译器无法推断内存大小
enum class Color; // 没问题！限域enum默认底层类型为int，内存大小确定

底层类型与前置声明的完整规则

1. 所有 enum 的底层类型是编译器为优化内存选择的整型（需覆盖所有枚举值的最小类型）；
2. 限域 enum：默认底层类型为int（也可显式指定），因此总能直接前置声明：

1
2

enum class Status; // 默认int，合法
enum class Status: std::uint32_t; // 显式指定底层类型，合法

1. 未限域 enum：无默认底层类型，仅显式指定底层类型时才能前置声明：

1

enum Color: std::uint8_t; // 显式指定底层类型，合法

1. 两者均可在定义时显式指定底层类型：

1
2

enum class Status: std::uint32_t { good = 0, failed = 1 };
enum Color: std::uint8_t { black, white, red };

未限域枚举的唯一实用场景：简化 std::tuple 字段访问

限域 enum 虽类型安全，但访问std::tuple字段时因无隐式转换，代码冗长；未限域 enum 可利用 “隐式转换为 std::size_t” 简化模板实参传递：

1
2
3
4
5
6
7
8
9
10
11

// 定义tuple类型（存储用户名、邮箱、声望值）
using UserInfo = std::tuple<std::string, std::string, std::size_t>;

// 未限域enum：简洁访问tuple字段（依赖隐式转换为std::size_t）
enum UserInfoFields { uiName, uiEmail, uiReputation };
UserInfo uInfo;
auto val = std::get<uiEmail>(uInfo); // 直接用枚举成员作为模板实参

// 限域enum：无隐式转换，代码冗长
enum class UserInfoFields { uiName, uiEmail, uiReputation };
auto val = std::get<static_cast<std::size_t>(UserInfoFields::uiEmail)>(uInfo);

限域枚举访问 tuple 的优化方案：toUType constexpr 函数模板

为兼顾限域 enum 的类型安全与 tuple 访问的简洁性，可实现编译期生效的toUType函数模板（转换枚举值为其底层类型）：

C++11 版本：

1
2
3
4
5
6

template<typename E>
constexpr typename std::underlying_type<E>::type
    toUType(E enumerator) noexcept
{
    return static_cast<typename std::underlying_type<E>::type>(enumerator);
}

C++14 简化版本（更简洁）：

1
2
3
4
5

template<typename E>
constexpr auto toUType(E enumerator) noexcept
{
    return static_cast<std::underlying_type_t<E>>(enumerator);
}

调用方式（兼顾安全与简洁）：

1

auto val = std::get<toUType(UserInfoFields::uiEmail)>(uInfo);

总结

• C++98风格的枚举类型，现在称为不限范围的枚举类型。
• 限定作用域的枚举类型仅在枚举类型内可见。它们只能通过强制类型转换以转换至其他类型。
• 限定作用域的枚举类型和不限范围的枚举类型都支持底层类型指定。限定作用域的枚举类型的默认底层类型是int，而不限范围的枚举类型没有默认底层类型。
• 限定作用域的枚举类型总是可以进行前置声明，而不限范围的枚举类型却只有在指定了默认底层类型的前提下才可以进行前置声明。

1. 不参与资源所有权共享，不影响指向对象的引用计数
2. 能检测自身是否悬空（过期），即指向的对象是否已被销毁
3. 无法直接解引用、无法直接判空，需借助 std::shared_ptr 实现安全访问

基础用法

创建

从 std::shared_ptr 直接创建，两者指向同一对象，且不会增加对象的引用计数：

1
2
3

auto spw = std::make_shared<Widget>(); // 对象引用计数(RC)=1
std::weak_ptr<Widget> wpw(spw);        // RC仍为1，wpw与spw指向同一对象
spw = nullptr;                         // RC=0，对象销毁，wpw悬空（过期）

安全访问对象（解决竞态条件）

单独调用 expired() 判断是否过期存在竞态风险（检查后到访问前，对象可能被其他线程销毁），需通过原子操作同时完成 “检查 + 访问”，有两种方式：

应用场景

std::weak_ptr 用于处理 shared_ptr 可能悬空的场景，有三类：

1. 可自动清理的缓存（工厂函数优化）

• 需求：工厂函数加载对象的操作昂贵，需缓存结果；同时要求对象无人使用时，缓存自动销毁，避免占用资源

• 实现方案：

  • 缓存容器存储 std::weak_ptr<const Widget>，不影响对象生命周期
  • 工厂函数返回 std::shared_ptr<const Widget>，由调用者管理对象生命周期
  • 每次请求时，通过 lock() 检查缓存对象是否有效，无效则重新加载并缓存

1
2
3
4
5
6
7
8
9
10

std::shared_ptr<const Widget> fastLoadWidget(WidgetID id)
{
    static std::unordered_map<WidgetID, std::weak_ptr<const Widget>> cache;
    auto objPtr = cache[id].lock(); // 原子化检查+获取
    if (!objPtr) {
        objPtr = loadWidget(id);    // 加载新对象
        cache[id] = objPtr;         // 存入缓存
    }
    return objPtr;
}

2. 观察者模式的观察者列表

• 需求：被观察者（subject）需持有观察者（observer）的指针，用于状态变更通知；但被观察者不控制观察者的生命周期，需避免访问已销毁的观察者
• 实现方案：被观察者的观察者列表存储 std::weak_ptr<Observer>，通知前通过 lock() 检查观察者是否有效，无效则跳过

3. 打破 std::shared_ptr 循环引用

• 问题：若两个对象互相持有对方的 std::shared_ptr，会形成循环引用，导致引用计数无法归零，对象无法销毁，造成内存泄漏
• 解决：将其中一方的 shared_ptr 替换为 weak_ptr，weak_ptr 不影响对方的引用计数，打破循环
• 补充：严格分层结构（如树）中，子节点生命周期由父节点管理，子到父的反向引用可用原始指针，无需 weak_ptr

效率特性

1. 大小：与 std::shared_ptr 相同
2. 底层：与 std::shared_ptr 共用控制块
3. 性能：构造、析构、赋值操作涉及原子操作，效率与 shared_ptr 基本一致
4. 引用计数细节：控制块存在两个引用计数，weak_ptr 操作的是第二个计数

总结

1. 用 std::weak_ptr 替代可能悬空的 std::shared_ptr，避免悬空访问的未定义行为
2. std::weak_ptr 的三大典型场景：缓存、观察者列表、打破 shared_ptr 循环引用

C++98 禁止函数调用的方案：私有声明 + 未定义

为阻止复制构造 / 赋值运算符被使用，C++98 采取 “声明为 private + 不定义” 的方式：

1
2
3
4
5
6
7
8

template <class charT, class traits = char_traits<charT>>
class basic_ios : public ios_base {
public:
    …
private:
    basic_ios(const basic_ios& );           // not defined
    basic_ios& operator=(const basic_ios&); // not defined
};

• 作用逻辑：private修饰阻止客户端代码调用；故意不定义函数，若成员 / 友元函数误调用，会在链接期触发 “缺少函数定义” 错误。
• 缺陷：报错时机晚，仅链接期提示错误，排查成本高。

C++11 更优方案：deleted 函数（= delete）

C++11 通过= delete标记函数为 deleted，实现禁止调用的目的：

1
2
3
4
5
6
7
8

template <class charT, class traits = char_traits<charT>>
class basic_ios : public ios_base {
public:
 ...
 basic_ios(const basic_ios&) = delete;
 basic_ios& operator=(const basic_ios&) = delete;
 ...
};

deleted 函数的基础优势（对比 C++98）

1. 调用限制更严格：deleted 函数无法以任何形式被调用（包括成员 / 友元函数调用），且编译期直接报错，报错时机更早、排查更易；
2. 错误提示更精准：deleted 函数建议声明为public（C++ 先检查访问性，再检查 deleted 状态），编译器会直接提示 “函数已被删除”，而非仅提示 “private”。

deleted 函数的扩展优势（C++98 方案无法实现）

private仅能作用于类成员函数，而任何函数都可标记为 deleted，典型场景如下：

1. 禁止非成员函数的不合理隐式调用：

过滤非目标类型的隐式转换调用（如仅允许 int 类型调用isLucky，禁止 char/bool/double）：

1
2
3
4

bool isLucky(int number);
bool isLucky(char) = delete;    // 拒绝char类型
bool isLucky(bool) = delete;    // 拒绝bool类型
bool isLucky(double) = delete;  // 拒绝float/double类型

1. 禁止模板的特定实例化：

拒绝模板针对void*/char*等特殊类型的实例化：

1
2
3
4
5
6
7
8

template<typename T>
void processPointer(T* ptr);

// 禁止void*和char*实例化
template<>
void processPointer<void>(void*) = delete;
template<>
void processPointer<char>(char*) = delete;

若需彻底禁止，还需删除const void*、const volatile void*、const char*、const volatile char*重载版本，以及std::wchar_t、std::char16_t、std::char32_t等字符类型的重载版本。

补充：private 无法实现类内模板函数的特定实例化禁止

模板特例化必须位于命名空间作用域，而非类作用域，因此在类内用private声明模板特化版本会直接编译错误；而 deleted 函数可在类外（命名空间作用域）删除类内模板的特化版本，无此限制：

1
2
3
4
5
6
7
8

class Widget {
public:
    template<typename T>
    void processPointer(T* ptr) { /* ... */ }
};
// 类外删除void*版本的特化，编译通过且实现禁止调用
template<>
void Widget::processPointer<void>(void*) = delete;

总结

• 优先选用删除函数，而非private函数
• 任何函数都可以删除，包括非成员函数和模板具现。

虚函数重写的约束条件

要想重写一个函数，必须满足下列要求：

• 基类中的函数必须是虚函数。
• 基类和派生类中的函数名字必须完全相同（析构函数例外）。
• 基类和派生类中的函数形参类型必须完全相同。
• 基类和派生类中的函数常量性必须完全相同。
• 基类和派生类中的函数返回值和异常规格必须兼容。
• 基类和派生类中的函数引用限定符必须完全相同。（C++11新增）

引用限定符：限定类的非静态成员函数只能被左值对象或右值对象调用。
带&的成员函数仅允许左值对象调用；
带&&的成员函数仅允许右值对象调用。

如果基类中的虚函数带有引用饰词，则派生类要对该函数进行改写版本必须也带有完全相同的引用饰词。否则相当于重新定义了一个新的函数。

编译器可能不报警但是存在错误的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class Base {
public:
    virtual void mf1() const;
    virtual void mf2(int x);
    virtual void mf3() &;
    void mf4() const;
};

class Derived: public Base {
public:
    virtual void mf1(); // mf1是声明为const的，而在派生类中没有
    virtual void mf2(unsigned int x); // mf2的形参类型是int，而在派生类中的则是unsigned int
    virtual void mf3() &&; // mf3带有左值引用限定符，而派生类中的则是右值引用限定符
    void mf4() const; // mf4未声明为虚函数
};

override 声明：显式保证重写正确性

通过在派生类函数后添加override声明，显式标明该函数意图改写基类虚函数版本：

• 编译器会强制校验所有重写条件，不满足则直接编译报错（而非运行时才暴露问题）；
• 额外价值：修改基类虚函数签名时，可通过 “编译报错的派生类数量” 衡量影响面，判断修改代价是否值得。
  例：

1
2
3
4
5
6
7

class Derived: public Base {
public:
    virtual void mf1() const override;  // 匹配const限定
    virtual void mf2(int x) override;   // 匹配int形参
    virtual void mf3() & override;      // 匹配左值引用限定
    void mf4() const override;          // 基类需补充virtual，否则仍报错
}; 

新增两个语境关键字：override和final

语言保留这两个关键字，但是仅在特定语境下保留。只在特定语境下用作关键字，其他情况下可用作变量名。

例：

1
2
3
4
5
6
7
8
9
10
11
12
13

class Warning {         //C++98潜在的传统类代码
public:
    …
    void override();    //C++98和C++11都合法（且含义相同）
    …
};

class Base { 
public: 
 virtual void func() final; // 禁止派生类重写func 
}; 
class FinalClass final {}; // 禁止FinalClass被继承 
// class SubClass : public FinalClass {}; // 编译错误

关于成员函数引用限定符

编写一个函数仅接受传入左值实参，需要声明一个非const左值引用形参：

1

void doSomething(Widget& w); // 仅接受左值的Widgets类型

编写一个函数仅接受传入右值实参，需要声明一个右值引用形参：

1

void doSomething(Widegt& w); // 仅接受右值的Widgets类型

成员函数引用限定符的作用就是针对发起成员函数调用的对象，即*this进行区分（是左值对象还是右值对象）；const限定符的作用就是约束*this的常量性（是否是const对象）

左值引用类型的重载版本返回的是一个左值引用（一个左值），右值引用类型的重载版本返回的是一个临时对象（一个右值）。

总结

• 为需要重写的函数添加override声明。
• 成员函数引用限定符使得对于左值和右值对象（*this）的处理能够区分开来。

Pimpl 的目的是减少编译依赖、加快编译速度：

• 传统写法中，Widget的头文件依赖std::string、std::vector、Gadget等头文件，一旦这些依赖变更，所有包含Widget.h的代码都要重新编译；
• Pimpl 把这些依赖移到.cpp文件中，头文件仅前向声明Impl结构体，用指针指向它，彻底切断 “头文件 - 实现依赖” 的关联。

C++98 用原始指针实现 Pimpl，现代 C++ 优先用std::unique_ptr（因为 pImpl 是 “独占所有权”），但直接用unique_ptr会踩坑。

用std::unique_ptr做 Pimpl 会编译报错

1. 报错现象

头文件仅前向声明Impl，用std::unique_ptr<Impl> pImpl，且未手动声明析构函数时，用户创建Widget对象会编译报错（提示 “sizeof/delete 应用到不完整类型”）：

1
2
3
4
5
6
7
8
9
10
11
12

// widget.h（有问题的写法）
class Widget {
public:
    Widget() : pImpl(std::make_unique<Impl>()) {} // 仅前向声明Impl
private:
    struct Impl;
    std::unique_ptr<Impl> pImpl;
};

// 客户代码（编译报错）
#include "widget.h"
Widget w; // 错误：Impl是不完整类型，unique_ptr析构时检查失败

2. 报错根源

• 编译器会自动生成Widget的析构函数（因为你没手动声明），且析构函数是inline的（在头文件里处理）；
• Widget析构时要调用unique_ptr<Impl>的析构函数，而unique_ptr的默认删除器会用static_assert检查：指向的类型必须是完整类型（有完整定义）；
• 但Impl在头文件里只是前向声明（不完整类型），因此触发编译错误。

特殊成员函数 “声明在.h，定义在.cpp”

要让unique_ptr正常工作，必须保证：在处理unique_ptr析构 / 移动逻辑时，Impl是完整类型（已在.cpp 里定义）。因此需要对 3 类特殊成员函数做统一处理：

1. 析构函数

• 头文件（.h）：仅声明析构函数，不定义；
• 实现文件（.cpp）：在Impl完整定义后，定义析构函数（哪怕用= default）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// widget.h
class Widget {
public:
    Widget();
    ~Widget(); // 仅声明
private:
    struct Impl;
    std::unique_ptr<Impl> pImpl;
};

// widget.cpp
#include "widget.h"
#include <string>
#include <vector>
#include "gadget.h"

// 先定义Impl（此时Impl是完整类型）
struct Widget::Impl {
    std::string name;
    std::vector<double> data;
    Gadget g1, g2, g3;
};

// 再定义析构函数（= default等价于编译器自动生成的逻辑）
Widget::~Widget() = default;
Widget::Widget() : pImpl(std::make_unique<Impl>()) {}

2. 移动操作（移动构造 / 移动赋值）

• 问题：声明析构函数后，编译器不会自动生成移动操作；若在.h 里用= default定义移动操作，会触发和析构一样的 “不完整类型” 报错；
• 解决：.h 里仅声明移动操作，.cpp 里在Impl定义后用= default定义（编译器生成的移动逻辑对unique_ptr是正确的 —— 移动指针所有权）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// widget.h
class Widget {
public:
    Widget();
    ~Widget();
    Widget(Widget&& rhs); // 仅声明
    Widget& operator=(Widget&& rhs); // 仅声明
private:
    struct Impl;
    std::unique_ptr<Impl> pImpl;
};

// widget.cpp
Widget::Widget(Widget&& rhs) = default; // 定义在Impl之后
Widget& operator=(Widget&& rhs) = default;

3. 拷贝操作（拷贝构造 / 拷贝赋值）

• 问题：

  1. 包含unique_ptr的类，编译器不会自动生成拷贝操作（unique_ptr是 “只可移动” 类型）；
  2. 即使生成，也是浅拷贝（仅复制指针，而非指针指向的Impl对象），不符合需求；

• 解决：.h 里声明拷贝操作，.cpp 里实现深拷贝（复制Impl对象而非指针）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// widget.h
class Widget {
public:
    Widget(const Widget& rhs); // 仅声明
    Widget& operator=(const Widget& rhs); // 仅声明
    // 其他声明...
};

// widget.cpp
// 拷贝构造：创建新的Impl对象，复制源对象的Impl内容
Widget::Widget(const Widget& rhs) : pImpl(std::make_unique<Impl>(*rhs.pImpl)) {}
// 拷贝赋值：直接复制Impl对象的内容（利用Impl自动生成的拷贝逻辑）
Widget& operator=(const Widget& rhs) {
    *pImpl = *rhs.pImpl;
    return *this;
}

std::unique_ptr 和 std::shared_ptr的差异

上述 “声明在.h、定义在.cpp” 的要求仅针对unique_ptr，用std::shared_ptr时完全不需要：

1
2
3
4
5
6
7
8
9
10
11
12
13

// widget.h（用shared_ptr的写法，无任何报错）
class Widget {
public:
    Widget() : pImpl(std::make_shared<Impl>()) {}
    // 无需声明析构/移动操作，编译器自动生成即可
private:
    struct Impl;
    std::shared_ptr<Impl> pImpl;
};

// 客户代码（正常编译）
Widget w1;
auto w2 = std::move(w1); // 移动构造正常

底层原因

• unique_ptr：删除器的类型是智能指针的一部分，为了效率，析构 / 移动时必须知道指向类型的完整定义；
• shared_ptr：删除器的类型不是智能指针的一部分，析构 / 移动时不需要指向类型完整，因此无需额外处理。

选型建议

• Pimpl 的核心是 “独占所有权”，因此unique_ptr是首选（符合语义），哪怕需要额外处理特殊成员函数；
• shared_ptr仅在需要 “共享所有权” 时使用，优势是无需处理特殊成员函数，但有引用计数的性能开销。

总结

1. Pimpl 的价值是减少编译依赖、加快编译速度，现代 C++ 优先用std::unique_ptr实现 Pimpl；
2. 对std::unique_ptr类型的 pImpl 指针，必须将析构、移动操作声明在头文件，定义在实现文件（拷贝操作需手动实现深拷贝），哪怕编译器自动生成的逻辑本身是正确的；
3. 上述要求仅适用于std::unique_ptr，std::shared_ptr无需额外处理特殊成员函数，但不符合 Pimpl 的 “独占所有权” 语义，仅在共享场景使用。

各 C++ 版本对 const_iterator 的支持差异

1. C++98：支持残缺，实用性差

const_iterator理论上符合规范，但实际使用存在两大痛点：

• 创建麻烦：非const容器无法直接获取const_iterator，需强制类型转换（或绑定到const引用）才能得到；

• 使用受限：insert/erase等容器操作仅接受iterator，且const_iterator无法可移植转换为iterator（即使reinterpret_cast也不行）；

  最终导致开发者被迫放弃使用，违背 “能const则const” 的准则。

1
2
3
4
5
6
7
8
9
10
11
12

typedef std::vector<int>::iterator IterT; 
typedef std::vector<int>::const_iterator ConstIterT; 

std::vector<int> values; 
… 
// 非const容器需强制转换才能获取const_iterator 
ConstIterT ci = 
 std::find(static_cast<ConstIterT>(values.begin()), 
     static_cast<ConstIterT>(values.end()), 
     1983); 
// insert不接受const_iterator，转换iterator也无可靠方法（编译失败） 
values.insert(static_cast<IterT>(ci), 1998);

C++11：支持完善，易用性大幅提升

解决了 C++98 的核心痛点，让const_iterator真正实用：

• 容器新增cbegin/cend成员函数，非const容器也能直接获取const_iterator；

• insert/erase等操作支持接收const_iterator，无需转换即可使用；

  示例：无需修改迭代器指向值的查找 + 插入场景，可直接用cbegin/cend获取const_iterator，代码简洁且符合规范。

1
2
3
4
5

std::vector<int> values; 
… 
// 直接用cbegin/cend获取const_iterator，insert原生支持 
auto it = std::find(values.cbegin(), values.cend(), 1983); 
values.insert(it, 1998);

C++11 的小缺陷与 C++14 的补全

• C++11 仅新增非成员函数begin/end，缺失cbegin/cend/rbegin/rend等；
• C++14 补全了这些非成员函数，满足 “最大程度通用的库代码” 需求（适配原生数组、仅提供自由函数接口的第三方库等）。

通用代码的适配方案（C++11 兼容）

若 C++11 环境下 STL 未提供非成员cbegin等函数，可自行实现（兼容普通容器和原生数组）：

• 核心逻辑：通过const引用接收容器 / 数组，调用 C++11 提供的非成员begin—— 对const容器 / 数组，begin会自动返回const_iterator（数组场景下等价于指向const的指针）；
• 无需依赖容器的cbegin成员函数，适配性更强。

总结

• 优先选用const_iterator，而非iterator。
• 在最通用的代码中，优先选用非成员函数版本的begin、end和rbegin等，而非其成员函数版本。

• constexpr对象：必然具备const只读属性，且必须由编译期可知的值完成初始化（技术上是翻译期，包含编译 + 链接，编程层面可视为编译期）。

• constexpr函数：不保证返回值是 const，也不保证结果一定编译期可知—— 结果是否编译期确定，完全取决于传入的实参：

  • 若实参是编译期已知的常量 → 结果在编译期计算，可用于 “整型常量表达式” 语境；
  • 若实参是运行期才能确定的值 → 函数退化为普通函数，在运行期计算结果。

编译期可知的常量整型值，可用于 C++ 要求 “整型常量表达式” 的核心语境：数组尺寸、整型模板实参（如std::array的长度）、枚举量的值、对齐修饰符（alignas）等。普通const对象无法满足这些场景（仅保证只读，不保证编译期初始化），因此：

所有constexpr对象都是const对象，但并非所有const对象都是constexpr对象。

constexpr函数的特性与限制：

1. 适用语境：可同时适配 “编译期常量计算” 和 “运行期普通计算”，无需为两种场景编写不同函数；

2. 类型限制：仅能接收和返回字面值类型（即编译期可确定值的类型，如内置类型、符合条件的自定义类型）；

3. 实现限制（C++ 版本差异）：

   • C++11：函数体仅允许 1 行 return 语句，需用三元运算符替代 if-else、递归替代循环；
   • C++14：限制大幅放宽，支持循环、局部变量、void 返回值，甚至允许修改对象状态的成员函数（如自定义类型的 setter）。

自定义类型对constexpr的支持：

• C++11：仅构造函数、返回字面值类型的 const getter 可声明为constexpr（成员函数隐式 const）；
• C++14：可将修改对象状态的 setter 声明为constexpr（void 返回值也允许），能基于编译期对象完成更复杂的编译期计算（如 Point 类的中点、镜像点计算）。

注意：constexpr是对象 / 函数接口的核心组成部分—— 声明后若随意移除（如函数新增 I/O 语句），依赖它的客户端代码（如用在模板参数、数组大小）会直接编译失败，需长期遵守。

总结

• constexpr对象都具备const属性，并由编译期已知的值完成初始化。
• constexpr函数在调用时若传入的实参值是编译器已知的，则会产出编译期结果。
• 比起非constexpr对象或constexpr函数而言，constexpr对象或是constexpr函数可以用在一个作用域更广的语境中。

多线程同时调用该 const 函数时，会出现 “不同线程读写同一块内存” 的数据竞争，导致程序行为未定义（即使逻辑上是 “读操作”）。

线程安全的解决方案

1. 基础方案：使用std::mutex

• 适用场景：需要同步多个变量 / 多个操作（如缓存值 + 缓存有效标记），保证操作的原子性；

• 实现要点：

  • 将std::mutex声明为mutable（因 const 成员函数中 mutex 被视为 const 对象，而锁 / 解锁操作会修改 mutex 状态）；
  • 用std::lock_guard自动加锁 / 解锁，避免手动解锁遗漏；

• 副作用：std::mutex不可拷贝 / 移动，导致包含它的类也不可拷贝 / 移动；

• 示例：多项式根缓存的线程安全实现（加锁后保证缓存计算 / 赋值的原子性）。

2. 轻量方案：使用std::atomic

• 适用场景：仅需同步单个变量（如函数调用次数统计），开销比 mutex 小；

• 实现要点：将统计变量声明为std::atomic<类型>且mutable，其操作是原子的（不可分割），避免数据竞争；

• 副作用：std::atomic同样不可拷贝 / 移动，导致包含它的类不可拷贝 / 移动；

• 坑点：绝对不能用于多个变量的同步（如缓存值 + 缓存有效标记）：

  • 先赋值缓存值、后标记有效：会导致多线程重复计算（违背缓存初衷）；
  • 先标记有效、后赋值缓存值：会导致线程读取到未赋值的脏数据。

例外情况：无需保证线程安全的场景

若能绝对保证 const 成员函数永远不会在多线程环境下调用（如仅用于单线程独占的类），可省略 mutex/atomic，避免资源开销和类拷贝 / 移动的限制；但这种场景越来越少见，优先保证线程安全。

总结

• 保证const成员函数的线程安全性，除非可以确信它们不会用在并发语境中。
• 运用std::atomic类型的变量会比运用互斥量提供更好的性能，但前者仅适用对单个变量或内存区域的操作。

指定初始化的方式包括使用小括号、使用等号，或是使用大括号：

1
2
3

int x(0);
int y = 0;
int z{0};

很多情况下使用一个等号和一对大括号也是可以的：（处理方式等同于只有大括号）

1

int z = {0};

对于用户定义的类型，等号的初始化方式实际并没有发生赋值：

1
2
3

Widget w1; // 调用的是默认构造函数
Widget w2 = w1; // 井非赋值，调用的是复制构造函数
w1 = w2;  // 并非赋值．调用的是复制赋值运算符

C++11引入了统一初始化：使用大括号进行初始化。

1. 使用大括号来制定容器的初始内容：

1

std: :vector<int> v{ 1, 3, 5 }; // v 的初始内容为1、3、5

1. 为非静态成员指定默认初始化值（也可以使用“=”，但是()不行）：

1
2
3
4
5
6
7
8

class Widget 
{ 
 ... 
private: 
 int x{ 0 }; // 可行，x 的默认值为 0 
 int y = 0; // 也可行 
 int z(0); // 不可行! 
};

不可复制对象（如std::atomic类型的对象）可以使用大括号和小括号来进行复制，但是不能使用“=”。

由上可以看出，只有大括号初始化适用于所有场景。

大括号初始化的特性

1. 禁止内建类型之间进行隐式窄化类型转换。如果大括号内的表达式无法保证能够采用进行初始化的对象来表达，则代码不能通过编译。
   如：

1
2

double x, y, z; 
int sum1{ x + y + z }; // 错误!double类型之和可能无法用int表达

1. 对于C++最令人苦恼的解析语法（MVP：任何能够解析为声明的都要解析为声明。最苦恼——程序员本来想要以默认方式构造一个对象，却不小心声明了一个函数）免疫。
   如：

1
2

Widget w1(); // 解析为函数声明（MVP问题） 
Widget w2{}; // 明确为对象初始化，无歧义

存在的缺陷

1. auto变量的异常推导

auto结合{}初始化时，变量类型会被推导为std::initializer_list（而非直觉类型）：

1
2
3

auto a = 10;          // 推导为int（符合直觉）
auto b{10};           // C++11/14：std::initializer_list<int>；C++17后：int
auto c = {10, 20};    // 始终推导为std::initializer_list<int>

2. 构造函数重载决议的优先级规则

• 无std::initializer_list形参时：()和{}初始化结果一致：

1
2
3
4
5
6
7
8
9
10

class Widget { 
public:  
    Widget(int i, bool b);      // 无std::initializer_list形参
    Widget(int i, double d);    
    …
};
Widget w1(10, true);            // 调用第一个构造函数
Widget w2{10, true};            // 调用第一个构造函数
Widget w3(10, 5.0);             // 调用第二个构造函数
Widget w4{10, 5.0};             // 调用第二个构造函数

• 有std::initializer_list形参时：{}会强制优先匹配该构造函数（即使普通构造更匹配）：

1
2
3
4
5
6
7
8
9
10
11

class Widget { 
public:  
    Widget(int i, bool b);      
    Widget(int i, double d);    
    Widget(std::initializer_list<long double> il); // 新增
    …
}; 
Widget w1(10, true);    // 调用第一个构造函数（()不受影响）
Widget w2{10, true};    // 调用std::initializer_list构造（10/true转long double）
Widget w3(10, 5.0);     // 调用第二个构造函数（()不受影响）
Widget w4{10, 5.0};     // 调用std::initializer_list构造（10/5.0转long double）

• 优先级极端性：即便std::initializer_list构造无法调用，编译器仍会优先尝试（失败才回退普通决议）：

1
2
3
4
5
6
7
8

class Widget { 
public: 
    Widget(int i, bool b);      
    Widget(int i, double d);    
    Widget(std::initializer_list<bool> il); // 元素类型为bool
    …
};
Widget w{10, 5.0};              // 错误！10/5.0转bool属于窄化转换，{}禁止

• 空{}的边界规则：空{}表示 “无实参”，优先调用默认构造（而非空std::initializer_list）；需传空列表时需嵌套括号：

1
2
3
4
5
6
7
8
9
10
11

class Widget { 
public:  
    Widget();                                   // 默认构造
    Widget(std::initializer_list<int> il);      // std::initializer_list构造
    …
};
Widget w1;                      // 调用默认构造
Widget w2{};                    // 调用默认构造
Widget w3();                    // MVP！声明函数
Widget w4({});                  // 调用std::initializer_list构造（空列表）
Widget w5{{}};                  // 同上

3. std::vector的()和{}初始化结果差异巨大

1
2

std::vector<int> v1(10, 20);    // 非std::initializer_list构造：10个元素，值均为20
std::vector<int> v2{10, 20};    // std::initializer_list构造：2个元素，值为10、20

总结

• 大括号初始化可以应用的语境最为宽泛，可以阻止隐式窄化类型转换，还对最令人苦恼之解析语法免疫。
• 在构造函数重载决议期间，只要有任何可能，大括号初始化物就会与带有std::initializer_list类型的形参相匹配，即使其他重载版本有着貌似更加匹配的形参表。
• 对于数值类型的std::vector来说使用大括号初始化和小括号初始化会造成巨大的不同
• 在模板内容进行对象创建时，到底应该使用小括号还是大括号会成为一个棘手问题。

noexcept的核心价值

性能层面：编译器最大化优化代码

• 逻辑：noexcept承诺 “函数异常传播时可直接终止程序”，编译器无需保证调用栈完整展开、局部对象按构造反序析构，因此可剔除冗余代码，生成更精简高效的机器码；
• 对比差异：noexcept函数的优化度远高于 C++98 的throw()或无异常声明的函数（后两者需预留栈展开的冗余代码）；

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// noexcept函数：编译器无冗余准备，极致优化
void moveWidget(Widget&& w) noexcept {
    // 无栈展开、析构顺序记录的冗余代码，机器码更精简
}

// throw()函数：需预留栈展开准备，优化有限（C++17已废弃）
void moveWidget(Widget&& w) throw() {
    // 含局部对象析构顺序记录、栈可展开维护的冗余代码
}

// 无声明函数：默认按“可能抛异常”处理，优化空间极小
void moveWidget(Widget&& w) {
    // 同throw()，冗余代码多，执行效率低
}

语义层面：作为接口承诺，支撑 STL 核心逻辑

• 逻辑：noexcept是函数接口的关键属性（与const同等重要），调用者 / STL 会依赖该承诺判断是否安全使用高性能逻辑；
• 支撑场景：

1. 移动操作（构造 / 赋值）：STL 容器仅当移动操作noexcept时，才会用 “移动” 替代 “拷贝”（避免移动抛异常破坏异常安全）；

1
2
3
4
5
6
7
8
9
10
11

// 移动构造加noexcept：STL容器优先用移动（高效且安全）
class Widget {
public:
    Widget(Widget&& other) noexcept {
        // 转移资源，无异常风险
    }
};

std::vector<Widget> vec;
Widget w;
vec.push_back(std::move(w)); // 容器调用移动构造（因noexcept）

1. swap函数：高层次结构（数组、std::pair）的swap是否noexcept依赖底层元素，加noexcept可让整个层级受益；

1
2
3
4
5
6
7
8
9
10
11

// 自定义Widget的swap加noexcept，支撑数组/pair的swap优化
class Widget {
public:
    void swap(Widget& other) noexcept {
        // 交换资源，无异常风险
    }
};

// 数组swap的noexcept依赖Widget::swap
Widget arr1[5], arr2[5];
std::swap(arr1, arr2); // 因Widget::swap noexcept，数组swap也noexcept

1. 析构 / 内存释放函数：C++11 默认隐式noexcept，无需显式声明，保证内存管理和对象销毁安全；

1
2
3
4
5
6
7
8
9
10
11

class Widget {
public:
    ~Widget() { // 默认隐式noexcept，无需显式写
        // 销毁资源，无异常风险
    }
};

// 内存释放函数默认noexcept
void operator delete(void* ptr) {
    // 释放内存，无异常风险
}

noexcept的适用 / 不适用场景

必加noexcept的场景

• 移动构造 / 移动赋值函数（STL 性能优化的核心）；
• swap函数（STL 算法核心，层级依赖其noexcept属性）；
• 析构函数、operator delete/delete[]（默认隐式noexcept，无需显式声明）；
• 无前置条件的宽泛契约函数，且确定永不抛异常；

1
2
3
4

// 宽泛契约（无前置条件），且确定不抛异常，加noexcept
int calculateSum(int a, int b) noexcept {
    return a + b;
}

绝对不加noexcept的场景

• 异常中立函数：自身不抛异常，但内部调用可能抛（加了会导致异常传播时程序直接终止）；

1
2
3
4
5
6

// 异常中立函数：内部调用可能抛的函数，不加noexcept
void processData(const std::string& data) {
    // 调用可能抛异常的函数（如new、文件操作）
    char* buf = new char[data.size()]; 
    // 允许异常传播到上层处理，不加noexcept
}

• 严格契约函数：有前置条件，检查条件时无法抛异常调试；

1
2
3
4
5
6
7

// 严格契约（前置条件：s.length()<=32），不加noexcept
void processShortString(const std::string& s) {
    // 调试时可抛异常提示前置条件违反，故不加noexcept
    if (s.length() > 32) {
        throw std::invalid_argument("string too long");
    }
}

• 为加noexcept扭曲实现（如捕获所有异常转状态码，增加代码复杂度）；

1
2
3
4
5
6
7
8
9
10

// 反例：为加noexcept扭曲实现，不推荐
int riskyFunc() noexcept {
    try {
        // 调用可能抛异常的函数
        return callUnsafeFunc();
    } catch (...) {
        // 捕获所有异常，返回错误码，增加复杂度
        return -1; 
    }
}

• 无法保证长期永不抛异常的函数（noexcept是接口承诺，修改会影响所有调用者）；

注意点

• 编译器不校验noexcept与函数实现的一致性：noexcept函数可调用无noexcept但实际不抛的函数（如 C 库、旧 C++98 函数），编译器不报错；

1
2
3
4

// noexcept函数调用无noexcept但实际不抛的C库函数，编译器允许
void processString(const char* str) noexcept {
    std::strlen(str); // C库函数，无noexcept但实际不抛
}

• 正确性优先于优化：永远不要为了加noexcept牺牲函数逻辑正确和接口稳定；
• 大多数函数是异常中立的，无需加noexcept；

总结

• 仅当确定函数永不抛异常时，才声明noexcept，其是函数接口的重要组成部分。
• noexcept函数可被编译器极致优化，且是 STL 移动语义、swap函数高效安全使用的核心支撑。
• 移动操作、swap函数是noexcept的核心适用场景，异常中立函数、严格契约函数等绝对不加noexcept。