模板推导与重载决议：先找候选，再比较转换

推导成功、候选可行、最终胜出是三个不同步骤；普通函数并非总胜过函数模板。

分析调用时，先根据名字查找得到候选，再对函数模板推导模板实参并检查约束，最后比较可行候选的实参转换和排序规则。函数模板不会先拿某种任意类型实例化，再尝试所有隐式转换。对于普通函数调用推导中的同一 T，如果两个参数给出冲突结论，通常直接推导失败，例如同一模板形参的两个按值参数不能同时由 int 和 double 推导成一个 T。明确指定模板实参则可能把问题变为已有形参类型上的转换。

按值参数的推导通常去掉实参顶层 const，并发生数组到指针等调整；引用参数可保留数组维度及被引用对象的 const。T&& 只有满足转发引用规则时，传入左值才会使 T 推导为左值引用，再经引用折叠形成左值引用参数。已经固定 T 的类模板成员参数 T&&，不能仅因写法相同就当作转发引用。返回类型、默认函数实参及嵌套类型等还可能落入非推导上下文，需要逐一识别。

若普通函数需要整型转换而函数模板产生精确匹配，模板可以获选。普通函数优先只是在相关转换比较等条件打平后适用的决胜规则之一。转发构造函数也可能比 const T& 复制构造更精确地匹配一个非 const 左值，因此无约束的通用入口容易抢走本来预期的调用。设计接口应限制真正接受的类型，并用少量覆盖 const、左值、右值和数组的编译测试固定行为。

template<class T> void pair_of(T, T);
// pair_of(1, 2.0);       // T 的推导冲突
pair_of<double>(1, 2.0);  // 参数类型已确定，随后检查转换

template<class T, std::size_t N>
constexpr std::size_t array_size(T (&)[N]) { return N; }

深入面试与自测

#include <cassert>
#include <cstddef>
#include <iostream>

constexpr int select(long) { return 1; }
template<class T> constexpr int select(T) { return 2; }
constexpr int tied(int) { return 3; }
template<class T> constexpr int tied(T) { return 4; }
template<class T, std::size_t N>
constexpr std::size_t extent(T (&)[N]) { return N; }

int main() {
    static_assert(select(1) == 2);
    static_assert(select(1L) == 1);
    static_assert(tied(1) == 3);
    const int a[] = {1, 2, 3};
    static_assert(extent(a) == 3);
    assert(extent(a) == 3);
    std::cout << "overload ok\n";
}

特化、名字查找与 ADL：声明位置为什么会改变结果

类模板偏特化、函数模板重载和函数模板显式特化承担不同角色；依赖调用还受定义上下文与 ADL 约束。

类模板可用偏特化对一族类型改变实现，函数模板不能偏特化。函数模板的显式特化依附某个主模板，不是与所有普通重载平等竞争的独立候选。若需要为一组参数形态改变函数行为，通常选择重载，或把分类逻辑放入可偏特化的类模板。特化声明应在相关使用触发实例化之前可见；把定义零散放在源文件中，容易让不同翻译单元得到不一致的认知。

模板中的非依赖名字主要在定义上下文完成查找；依赖调用需要按照模板规则组合候选，不能理解为实例化时把此刻所有同名函数重新搜一遍。对未限定函数调用，ADL 还会根据实参类型寻找关联命名空间中的声明。单纯把一个同名函数写在模板后面，并不能保证它会加入普通名字查找的候选集合。

泛型交换常写 using std::swap; swap(a,b);，使通用候选和类型关联命名空间中的定制函数都能参与。直接写 std::swap(a,b) 是限定调用，不走同样的 ADL 定制路径。类型内部定义的隐藏友元也可由 ADL 找到，但不应据此扩大对任何名字和任何表达式的推断。工程上应选择清楚、窄小的定制入口，避免在无关命名空间堆积通用重载。

namespace model {
struct Item { int value; };
void swap(Item& a, Item& b) noexcept {
    int old = a.value; a.value = b.value; b.value = old;
}
}
template<class T> void exchange(T& a, T& b) {
    using std::swap;
    swap(a, b); // 未限定调用允许 ADL 找到 model::swap
}

深入面试与自测

SFINAE 与 concepts：把错误挡在接口边界

替换失败、约束不满足和函数体实例化错误不是同一件事；约束排序依赖可识别的结构，而非任意数学推理。

C++17 的 SFINAE 允许某些发生在直接上下文中的替换失败移除候选。若错误出现在为了检查候选而实例化的其他类模板或函数体中，未必受这层机制保护。仅把代码包装进模板或 decltype，并不能保证所有错误都变成可恢复的候选淘汰。检测惯用法应测试接口实际需要的表达式，并区分表达式是否合法、结果类型是否合适以及运行期契约是否成立。

C++20 concepts 把约束写在模板接口处，可通过 requires 表达式检查操作、类型或返回结果。约束不满足通常意味着该候选不可用，便于组织回退重载；但语法约束不能证明排序关系具有传递性，也不能证明对象寿命和线程安全。合法表达式与语义模型需要分别论证。一个能编译的比较器，仍可能不满足算法的严格弱序要求。

约束的更强关系采用规范化与原子约束身份等规则，不是通用逻辑证明器。设计更精细概念时，可复用已有命名概念，再增加条件，便于建立可识别的蕴含结构。重复书写看起来等价的表达式不一定获得预期的排序；相互交叉而无法比较的约束可能导致歧义。库接口应有清楚的约束层次，并为重叠类型建立编译测试。

template<class T> concept Integral = std::is_integral_v<T>;
template<class T> concept SignedIntegral = Integral<T> && std::is_signed_v<T>;

template<Integral T> void encode(T);
template<SignedIntegral T> void encode(T);
// SignedIntegral 复用 Integral，形成清楚的约束层次。

深入面试与自测

#include <cassert>
#include <iostream>
#include <type_traits>

template<class T> concept Integral = std::is_integral_v<T>;
template<class T> concept SignedIntegral = Integral<T> && std::is_signed_v<T>;
template<class T> constexpr int route(T) { return 0; }
template<Integral T> constexpr int route(T) { return 1; }
template<SignedIntegral T> constexpr int route(T) { return 2; }

int main() {
    static_assert(route(1.5) == 0);
    static_assert(route(1u) == 1);
    static_assert(route(1) == 2);
    assert(route(-2) == 2);
    std::cout << "constraints ok\n";
}

optional 与 variant：让缺失、失败和状态转换可区分

optional 表示值可缺失，variant 表示若干备选类型之一；二者能减少无效状态，但不会自动建立业务状态机。

optional<T> 管理一个可能存在的 T 的寿命。无值可以表达“没有查询结果”，但如果同时需要区分超时、权限错误和数据不存在，单个 optional 不足以携带原因。C++17/20 可设计带明确错误类型的结果结构或 variant；不要使用一个默认构造的 T 同时代表合法值和失败。访问前检查条件，或者使用会报告缺失的接口，不能把未检查的解引用当成可靠错误处理。

variant 用一个活动备选类型表示当前状态，适合替代多组可能互相矛盾的布尔标志。std::visit 的访问器需要处理可发生的备选组合；精确的访问器重载还能帮助新增状态时暴露遗漏。不过，默认构造选择什么备选、类型转换如何选入、状态是否允许转移，仍需要接口定义。对外暴露任意 emplace，可能让调用者绕开状态迁移规则。

variant 在某些抛异常的类型变更操作中可能进入 valueless_by_exception 状态。并非任何异常都必然导致这种状态，也不能用一次具体实现测试把“本次保留旧值”当成普遍强异常保证。应检查备选类型的构造与移动性质，在状态切换前准备临时结果，必要时采用不抛出的提交操作或独立拥有者。异常安全等级由整个迁移过程决定，不能只看外层类型叫 variant。

using Result = std::variant<Value, ParseError>;
// 不用 optional<Value> 同时表达“没有值”与任意失败原因。

std::optional<bool> setting = false;
if (setting.has_value()) {
    bool enabled = *setting; // enabled 为 false，setting 仍有值
}

深入面试与自测

#include <cassert>
#include <iostream>
#include <optional>
#include <variant>

struct Idle {};
struct Running { int id; };
struct Finished { int value; };
struct Failed { int code; };
using State = std::variant<Idle, Running, Finished, Failed>;
bool start(State& state, int id) {
    if (!std::holds_alternative<Idle>(state) || id <= 0) return false;
    state = Running{id};
    return true;
}
bool complete(State& state, std::optional<int> result) {
    if (!std::holds_alternative<Running>(state)) return false;
    if (result) state = Finished{*result};
    else state = Failed{1};
    return true;
}
int main() {
    State state = Idle{};
    const bool early = complete(state, 7);
    assert(!early);
    const bool invalid = start(state, 0);
    assert(!invalid);
    const bool begun = start(state, 10);
    assert(begun);
    const bool duplicate = start(state, 20);
    assert(!duplicate);
    const bool finished = complete(state, 0);
    assert(finished);
    assert(std::get<Finished>(state).value == 0);
    const bool repeated = complete(state, 9);
    assert(!repeated);
    State failed = Idle{};
    const bool second_begun = start(failed, 11);
    assert(second_begun);
    const bool second_finished = complete(failed, std::nullopt);
    assert(second_finished);
    assert(std::get<Failed>(failed).code == 1);
    std::cout << "state transitions ok\n";
}

string_view、span 与 ranges：借用的到底是谁的寿命

view 本身轻量不代表底层资源安全；borrowed_range 描述迭代器与范围对象的关系，不承诺被借用内存永生。

string_view 和 span 保存对已有连续存储的观察能力，不接管底层字符或元素的寿命。复制一个 view 只是复制借用关系。返回局部 string 的 view、让 vector 扩容后继续使用旧 span，都会破坏这层关系。const view 或只读元素只能限制修改方式，不能阻止拥有者销毁、释放或搬迁存储。接口必须交代拥有者、有效期及使句柄失效的操作。

ranges 算法的返回类型会利用 borrowed_range 等概念减少部分临时范围造成的悬空。例如对非借用的临时拥有型范围查找，相关算法可返回 dangling 标记，阻止把结果误当成可解引用迭代器。对 span 这类范围对象，迭代器有效性不依赖这个轻量 span 对象自身是否还存在，但仍依赖被引用数组的寿命和稳定性。因此 borrowed_range 不能修复一个创建时已经悬空的 span。

惰性视图还可能把谓词、投影或其他视图保存在内部；实际迭代时才执行工作。如果 lambda 捕获了已经离开作用域的局部引用，保留底层容器也不够。分析组合管道要分别追踪拥有型范围、引用型视图、谓词对象及迭代器是否依赖父视图。跨线程或异步任务若无法证明所有借用寿命，通常应传递明确的拥有者或复制必要数据。

std::vector<int> owner = {1, 2, 3};
std::span<int> view(owner);
// owner.push_back(4) 若引发重新分配，view 保存的地址会失效。

// 某些 ranges 算法针对临时拥有型范围返回 dangling，
// 但 std::span<int>(dangling_pointer, n) 无法让失效指针重新合法。

深入面试与自测

#include <algorithm>
#include <cassert>
#include <concepts>
#include <iostream>
#include <ranges>
#include <span>
#include <vector>

int main() {
    int owner[] = {10, 20, 30};
    std::span<int> view(owner);
    static_assert(std::ranges::borrowed_range<std::span<int>>);
    static_assert(!std::ranges::borrowed_range<std::vector<int>>);
    using TemporaryResult = decltype(std::ranges::find(std::vector<int>{1, 2}, 2));
    static_assert(std::same_as<TemporaryResult, std::ranges::dangling>);
    auto position = std::ranges::find(view, 20);
    assert(position != view.end());
    assert(*position == 20);
    std::cout << "borrowed range ok\n";
}

release/acquire：沿着读取来源建立 happens-before

要证明普通数据可安全读取，必须指出 acquire 实际读到了哪次发布，而不是只在两边写上内存序名称。

单次发布的典型关系是：生产者先写普通数据，再对某个原子状态执行 release；消费者用 acquire 读取同一原子状态，并确实读到该发布或规则允许的释放序列来源后，再读普通数据。线程内的先后关系与这条同步边共同把数据写入连接到读取。没有这条边，原子标志本身无数据竞争，并不意味着标志旁边的普通数据可以并发读写。

可把证明画成四个点：W(data) → store(flag, release) → load(flag, acquire) → R(data)。中间不是任意两次原子操作之间都存在的箭头，必须核对读取来源和版本。acquire 若仍读到初值，就没有获得本次发布的保证；读完后生产者再次改写普通 data，也不被上一次发布自动保护。单次不可变发布与可重复覆盖的信箱是不同协议，后者还需确认消费完成、分配独立槽位或使用其他同步。

relaxed 可以满足仅需原子性、无需借它发布其他数据的场景，例如独立统计计数，但不能以某个平台本次测试正确替代语言层证明。seq_cst 提供更强的原子操作顺序约束，却也不会自动延长对象寿命或修复读写没有按协议隔离的问题。释放序列等细节还应按目标标准版本核对，避免把历史版本规则无条件套到 C++20。

生产者：W(payload) ──sequenced-before──> flag.store(true, release)
                                             │
                  acquire 确实读取这次发布 ────┘ synchronizes-with
                                             ↓
消费者：flag.load(acquire)==true ───────────> R(payload)

前提：payload 在发布后不再被并发改写，且寿命覆盖消费者使用。

深入面试与自测

#include <atomic>
#include <cassert>
#include <iostream>
#include <thread>

struct Payload { int value = 0; int check = 0; };
int main() {
    Payload payload;
    std::atomic<bool> ready{false};
    std::thread reader([&] {
        while (!ready.load(std::memory_order_acquire)) std::this_thread::yield();
        assert(payload.value == 42);
        assert(payload.check == 84);
    });
    std::thread writer([&] {
        payload.value = 42;
        payload.check = 84;
        ready.store(true, std::memory_order_release);
    });
    writer.join();
    reader.join();
    std::cout << "release-acquire ok\n";
}

CAS、ABA 与安全回收：原子更新之后还缺什么

比较交换只决定某次值更新；对象是否仍活着、算法能否持续推进，都需要独立的协议和证明。

compare_exchange 比较当前原子值与 expected，成功时写入 desired，失败时会用观察到的值更新 expected。weak 允许伪失败，常用于重试循环；strong 避免这种伪失败，但并不避免真实竞争，更不解决 ABA。重试循环必须按新的 expected 重算依赖它的 desired，不能重复使用基于旧节点或旧计数推导的更新。成功和失败路径的内存序也应分别对应实际读写需求。

ABA 指值从 A 变为其他值再变回 A，使只比较当前值的操作无法察觉历史变化。对链式结构，地址相同还可能对应已删除后重新分配的另一个对象。计数标签能够检测一些历史变化，但仍需分析计数回绕、原子宽度支持和对象解引用时的寿命；把地址与版本一起比较，不会让已经释放的节点重新合法。一个线程在读取 next 之前就可能遭遇回收，甚至还没有机会执行 CAS。

安全回收必须规定何时可以把移除节点真正销毁并复用。Hazard pointer 思路是发布正在使用的节点，并在发布后验证来源仍然符合协议；移除者退休节点，确认没有保护者后才回收。Epoch 等方法采用不同的读侧与静止点约定，也有延迟回收和停滞线程方面的取舍。C++17/20 没有在标准库中提供一套通用 hazard pointer 容器实现，工程上应使用经过审查的实现并明确限制，不能把几行原子指针代码直接称作完整无锁队列。

进展保证也要分层。某个 atomic 类型的操作是否 lock-free 由类型和实现决定，可检查相应属性；一段算法即使使用无锁原子，也可能调用阻塞分配器、等待外部 I/O 或无限重试。系统整体持续有操作完成的 lock-free，与每个操作都有有界步骤的 wait-free 不同。评估时分别看正确性、饥饿风险、尾延迟、内存回收成本和实际吞吐，不以“没有 mutex”作为性能结论。

// 安全回收示意，不是可直接运行的完整算法：
读取候选 p → 按协议发布保护 → 重新验证 p 仍是有效候选
           → 访问 p 的字段 → 完成操作 → 清除保护
移除节点 → 放入退休集合 → 满足无保护者等回收条件 → 销毁/复用

// CAS 失败后 expected 已变化，desired 若依赖 expected 必须重算。

深入面试与自测

协程取消与资源生命周期：谁有权恢复，谁负责销毁

co_await 提供挂起机制，不自带执行器、取消协议或自动拥有者；必须把完成、取消、恢复和销毁的竞态统一管理。

C++20 协程把跨挂起点保留的状态放入协程状态对象，调用方拿到的返回对象与 coroutine_handle 如何管理该状态，由类型设计决定。按值参数可以进入协程参数副本，但引用参数仍然借用原对象，成员协程也不会因为挂起就自动延长 this 指向对象的寿命。initial_suspend 和 final_suspend 的策略影响何时开始、何时保留帧，以及最终由谁销毁。

取消首先是协议请求。任务可能停在 I/O、定时器、队列或计算内部，不同等待点需要不同的唤醒与收尾机制。取消请求和正常完成可能同时发生，必须定义哪个状态转换赢得一次性完成权；失败的一方不得再恢复同一协程。若底层操作不可取消，需要保持它引用的缓冲和完成状态有效，直到实际完成，或选择隔离资源并放宽时限承诺。

直接调用 handle.destroy() 不是通用取消按钮。销毁要求协程处于合适的挂起状态，且还要保证没有线程正在恢复或即将再次使用该句柄。异步完成队列中遗留的回调可能在销毁后执行，形成悬空恢复。可靠任务拥有者应先阻止新的恢复来源，处理或撤销已登记回调，并在确认没有在途执行后完成销毁。

await_suspend 负责登记异步继续执行时，句柄一旦被发布，别的线程就可能恢复协程；因此不能无条件认为 await_suspend 返回前 awaiter 和帧必然仍可访问。还应避免持有要求同线程解锁的 mutex 跨越可能换线程恢复的挂起点。审查协程应画出运行、挂起、完成、取消、销毁的状态图，逐项检查所有权与一次性转换，而不是只把同步函数改写为 co_await。

运行 → 登记异步操作并挂起 → 完成方/取消方竞争一次性完成权
                               ↓
                   唤醒协程 → 取结果或处理取消 → final_suspend
                               ↓
       拥有者确认没有在途恢复和外部借用 → 销毁帧

该图是协议审查框架；具体事件循环、I/O API 与 promise 类型仍需实现。

深入面试与自测