standrad c++

C++20 引入了协程（coroutines）这一强大的语法结构，标志着 C++ 在异步编程领域迈出了重要一步。相比传统的回调、promise、Future 等方式，协程通过让函数“挂起”和“恢复”，极大地提升了代码可读性和可维护性。本文将从几个关键维度解析协程带来的实际收益，并给出一些常见的使用场景与最佳实践。

1. 语义与实现的分离

传统的异步代码往往将业务逻辑与状态机拆分，业务层编写回调，状态机由框架实现，导致业务代码难以直接阅读。协程将“挂起”点写在业务代码中，编译器会自动生成状态机，开发者只需关注业务逻辑。这样，逻辑与实现完全解耦，业务层的代码几乎保持同步风格，极大提升了代码可读性。

2. 更直观的错误传播

在传统异步模式中，错误往往通过多层回调链传递，导致错误处理代码被拆散。协程则可以直接使用 try/catch，与同步代码错误处理方式保持一致。错误不需要手动包装成 std::future 或 boost::exception，异常可以自然传播到调用者，保持错误处理逻辑的连贯性。

3. 高效的资源管理

协程的生命周期由编译器生成的状态机负责，所有局部对象都被正确构造和销毁。相比于手写的 std::promise 或 std::packaged_task，协程可以避免多余的栈帧和堆分配，进一步降低运行时开销。

4. 与异步 IO 的天然兼容

C++20 的协程与标准库的 `

`、“、“ 等模块配合得天衣无缝。可以在协程中使用 `co_await std::chrono::steady_clock::now()` 轻松实现延时；使用 `co_await std::async` 直接等待异步任务完成；甚至可以自定义 awaitable 类型，让协程挂起在自己的 I/O 操作上，进一步简化异步 I/O 编程。 ## 5. 简化链式异步调用 在传统模式中，若需要多级异步调用，往往出现“回调地狱”。协程通过 `co_await` 的链式调用，几行代码即可完成多步异步处理，极大减少了代码层级和潜在错误。示例： “`cpp std::future fetch_user_id(); std::future fetch_user_name(int id); std::future fetch_user_profile(int id); async auto get_profile_name() -> std::future { int id = co_await fetch_user_id(); // 1 std::string name = co_await fetch_user_name(id); // 2 std::string profile = co_await fetch_user_profile(id); // 3 co_return name + ” (” + profile + “)”; } “` 上述代码直观清晰，几乎与同步代码无异。 ## 6. 性能与成本 虽然协程在语法上提供了强大便利，但并非所有场景都适用。协程生成的状态机会占用一定内存，且 `co_yield`/`co_return` 的实现涉及对象复制或移动。对于极低延迟或极高吞吐量的场景，仍需衡量是否使用协程。总体而言，对于业务逻辑复杂、涉及多层异步、可读性优先的场景，协程提供了显著优势。 ## 7. 最佳实践与常见陷阱 | 建议 | 说明 | |——|——| | **避免过度嵌套** | 过深的协程嵌套会导致状态机复杂，调试困难。应将协程拆分为更小的单元，保持单一职责。 | | **控制异常传播** | 协程内部若捕获异常并自行处理，应确保不抛出未捕获异常导致 `std::terminate`。 | | **慎用 `co_yield`** | 若仅需要一次性返回值，直接使用 `co_return`；`co_yield` 主要用于生成器模式。 | | **了解 awaitable 的实现** | 自定义 awaitable 时需确保 `await_suspend` 的返回值与 `await_resume` 的行为一致，避免挂起/恢复异常。 | | **避免无用拷贝** | 通过 `std::move` 或 `std::forward` 传递大型对象，防止协程生成的状态机中产生多余拷贝。 | ## 8. 典型应用场景 1. **网络 I/O**：结合 `asio`、`libuv` 等库，自定义 awaitable，实现在协程中无阻塞网络请求。 2. **文件系统**：使用 `std::experimental::filesystem` 与协程配合，实现异步文件读写。 3. **游戏引擎**：协程可用于控制游戏逻辑流程（如等待用户输入、动画完成），保持主循环简洁。 4. **后台服务**：处理多用户请求时，协程可在单线程中并发处理，减少线程切换成本。 5. **可视化编程**：在 UI 线程中使用协程等待动画结束或输入事件，避免 UI 阻塞。 ## 9. 结语 C++20 的协程是一次深度语言演进，它通过让异步流程看起来像同步代码，极大提升了代码的可读性、可维护性和错误处理的简洁性。虽然在性能上需要细致评估，但在大多数业务级别应用中，协程已成为处理异步任务的首选方案。熟悉协程语义、掌握 awaitable 的实现以及遵循最佳实践，将使我们在 C++ 的异步编程路上走得更快、更稳。

在 C++17 之后，利用折叠表达式和递归模板元编程，可以轻松实现将可变参数模板的类型序列或参数列表按逆序排列。下面给出两种常见需求的实现：一种是对类型列表进行反转，另一种是对函数参数包进行逆序调用。

1. 对类型列表进行反转

1.1 关键点

• 类型列表：用 std::tuple 或自定义的 type_list 存储类型序列。
• 递归拆分：将第一个类型取出，递归处理剩余类型，最后在拼接阶段把第一个类型放到尾部。
• C++17 语法糖：使用 decltype、折叠表达式和 auto 进行更简洁的实现。

1.2 代码实现

#include <tuple>
#include <type_traits>
#include <iostream>

// 自定义类型列表
template<typename... Ts> struct type_list {};

// 递归反转
template<typename TL>
struct reverse;

// 递归终止：空列表
template<>
struct reverse<type_list<>> {
    using type = type_list<>;
};

// 递归步骤：拆分第一个类型
template<typename T, typename... Rest>
struct reverse<type_list<T, Rest...>> {
    using type = typename concat<type_list<Rest...>, type_list<T>>::type;
};

// 合并两个类型列表
template<typename TL1, typename TL2>
struct concat;

template<typename... Ts1, typename... Ts2>
struct concat<type_list<Ts1...>, type_list<Ts2...>> {
    using type = type_list<Ts1..., Ts2...>;
};

// 用法示例
using original = type_list<int, double, char, std::string>;
using reversed = reverse <original>::type;

int main() {
    // 通过静态断言验证
    static_assert(std::is_same_v<reversed, type_list<std::string, char, double, int>>);
    std::cout << "类型列表已反转！\n";
}

说明

1. concat 用于把两段类型列表拼接。
2. reverse 通过拆分第一个类型并递归处理剩余部分，最终把拆出的类型放到结果列表末尾。
3. 采用 static_assert 可在编译期验证结果正确。

2. 对可变参数函数调用进行逆序

2.1 场景

你可能希望在某些库中，使用可变参数模板实现一个 print 函数，输出参数时保持原来的顺序，但你想要逆序打印。或更一般地，想把一个函数包 f 以逆序依次应用到参数列表上。

2.2 逆序调用实现

#include <iostream>
#include <utility>

// 递归终止：空参数包
void reverse_print() {
    std::cout << "完成逆序打印。\n";
}

// 递归步骤：先打印后面，再打印当前
template<typename T, typename... Rest>
void reverse_print(T&& first, Rest&&... rest) {
    // 递归打印剩余
    reverse_print(std::forward <Rest>(rest)...);
    // 再打印当前
    std::cout << std::forward<T>(first) << ' ';
}

// 逆序执行任意可变参数函数
template<typename Func, typename... Args>
auto reverse_apply(Func&& f, Args&&... args) {
    // 先展开剩余参数
    return reverse_apply_impl(std::forward <Func>(f),
                              std::index_sequence_for<Args...>{},
                              std::forward <Args>(args)...);
}

// 内部实现：通过索引序列逆序调用
template<typename Func, std::size_t... Is, typename... Args>
auto reverse_apply_impl(Func&& f,
                        std::index_sequence<Is...>,
                        Args&&... args) {
    // 通过折叠表达式逆序调用
    return ((f(std::get <Is>(std::forward_as_tuple(args...)))), ...);
}

// 示例函数
void foo(int a) { std::cout << "foo(" << a << ")\n"; }

int main() {
    // 逆序打印
    reverse_print(1, 2.5, "hello", std::string("world"));
    // 逆序执行 foo
    reverse_apply(foo, 10, 20, 30);
}

关键点

1. reverse_print 先递归处理剩余参数，再打印当前，从而实现逆序。
2. reverse_apply 利用 std::index_sequence 生成索引序列，然后通过折叠表达式 ((f(...)), ...) 按逆序调用 f。
3. 这两种方式都保持了 完美转发（std::forward），兼容左值、右值。

3. 小结

• 类型列表反转：通过递归拆分和拼接实现，适用于编译期类型操作。
• 参数包逆序调用：利用递归或折叠表达式实现，适用于运行时函数调用。
• 两种技术都展示了 C++ 模板元编程的强大与灵活。希望你在自己的项目中能灵活运用这些模式。

在多线程环境下实现一个线程安全且懒加载的单例模式，最常用的方式是采用C++11之后的std::call_once和std::once_flag，或者利用局部静态变量的线程安全初始化特性。下面分别展示两种实现方式，并对其优缺点进行分析。

1. 使用 std::call_once

#include <iostream>
#include <mutex>
#include <memory>

class Singleton {
public:
    // 获取实例的静态成员函数
    static Singleton& instance() {
        std::call_once(initFlag, [](){
            instancePtr.reset(new Singleton);
        });
        return *instancePtr;
    }

    // 其它业务接口
    void doSomething() {
        std::cout << "Singleton doing something.\n";
    }

private:
    // 私有构造函数，防止外部直接创建
    Singleton() { std::cout << "Singleton constructed.\n"; }

    // 禁止拷贝构造和赋值
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;

    static std::once_flag initFlag;
    static std::unique_ptr <Singleton> instancePtr;
};

// 静态成员定义
std::once_flag Singleton::initFlag;
std::unique_ptr <Singleton> Singleton::instancePtr = nullptr;

优点

• 线程安全且只初始化一次。
• 通过 std::once_flag 与 std::call_once 的组合，避免了锁竞争。
• 对构造函数进行显式控制，易于定制初始化逻辑。

缺点

• 需要手动维护静态指针，稍显繁琐。
• 若在多进程或 DLL 共享内存环境下使用，需要注意符号导出问题。

2. 利用局部静态变量（C++11 及以后）

class Singleton {
public:
    static Singleton& instance() {
        static Singleton instance; // C++11 之后保证线程安全
        return instance;
    }

    void doSomething() {
        std::cout << "Singleton doing something.\n";
    }

private:
    Singleton() { std::cout << "Singleton constructed.\n"; }
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;
};

优点

• 代码最简洁，几乎不需要手动管理。
• 标准保证局部静态变量在第一次使用时线程安全初始化。

缺点

• 若 Singleton 的构造函数抛异常，后续调用 instance() 仍会重新尝试初始化，可能导致性能问题。
• 对于需要在程序退出时显式销毁对象的场景（例如需要特定顺序销毁全局对象）不够灵活。

3. 何时选用哪种方式？

场景	推荐实现
需要在单例初始化时做复杂逻辑，且需要确保仅初始化一次	std::call_once
单例构造轻量、无异常抛出、且希望代码极简	局部静态变量
需要在多进程或 DLL 中共享同一实例	需结合 std::call_once 与合适的符号导出/共享机制

4. 小结

在现代 C++（C++11 及以后）中，最常见的实现单例模式的两种方式已经足够满足大多数场景。std::call_once 提供了更细粒度的控制，适合需要自定义初始化流程的复杂单例；而局部静态变量的方式则更加简洁、易于维护。理解两者的内部实现原理可以帮助我们在多线程环境中做出更合理的选择。

在C++11之后，智能指针成为管理动态资源的首选工具。最常见的两种智能指针是std::shared_ptr和std::weak_ptr，它们各自承担着不同的职责，了解它们的区别与使用场景能帮助你写出更安全、更高效的代码。

1. 基本概念

• std::shared_ptr
  通过引用计数来管理同一块资源。每个shared_ptr实例都会持有一个计数器，当计数器为0时，资源会被销毁。所有持有该资源的shared_ptr都能直接访问对象。

• std::weak_ptr
  只维护一个弱引用，不参与引用计数。它能“观察”一个对象，但不影响对象的生命周期。使用weak_ptr可以避免shared_ptr之间形成的强引用循环。

2. 关键区别

维度	std::shared_ptr	std::weak_ptr
引用计数	参与计数	不参与计数
对象生命周期	控制	观察
内存占用	较大（引用计数结构）	较小
用法	直接使用对象	需要先转成shared_ptr才可使用
是否能空	只能为非空（除非构造为空）	可为空

3. 使用场景

3.1 共享所有权

当多个部件需要共同拥有同一个资源，且资源应在最后一个拥有者销毁时释放时，使用shared_ptr。典型例子：

class Node {
public:
    std::vector<std::shared_ptr<Node>> children;
};

3.2 防止循环引用

在树、图等结构中，父子节点往往互相引用。若都用shared_ptr会导致引用计数永不归零，导致内存泄漏。此时父节点用shared_ptr指向子节点，子节点用weak_ptr指向父节点：

class Node {
public:
    std::weak_ptr <Node> parent;
    std::vector<std::shared_ptr<Node>> children;
};

3.3 缓存/观察者模式

如果你需要观察一个对象但不想延长它的生命周期，可以使用weak_ptr。例如，线程池的工作线程持有任务对象的weak_ptr，在取任务时先 lock() 转为 shared_ptr，确保任务仍存在：

std::weak_ptr <Task> weakTask = getTask();
if (auto task = weakTask.lock()) {
    task->execute();
}

3.4 延迟初始化与懒加载

weak_ptr可以在对象存在时保持引用，避免重复创建。例如，一个图像缓存：

class ImageCache {
    std::unordered_map<std::string, std::weak_ptr<Image>> cache;
public:
    std::shared_ptr <Image> get(const std::string& id) {
        if (auto sp = cache[id].lock()) return sp;
        auto newImg = std::make_shared <Image>(id);
        cache[id] = newImg;
        return newImg;
    }
};

4. 常见坑与最佳实践

1. 忘记 lock()
weak_ptr不能直接解引用，需先 lock()。如果忘记，会抛出异常或产生未定义行为。

2. 多线程竞争
   weak_ptr::lock() 的原子性取决于实现。若多线程频繁访问同一对象，最好使用std::shared_ptr的拷贝或std::atomic<std::shared_ptr<...>>。

3. 与 std::unique_ptr 混用
   unique_ptr 与 shared_ptr/weak_ptr 互不兼容。若需要同时拥有独占与共享所有权，需在合适时机进行转换：`std::unique_ptr

   up; auto sp = std::make_shared(std::move(up));`

4. 异常安全
   shared_ptr 的引用计数操作是异常安全的，但 weak_ptr 的 lock() 可能抛出 bad_weak_ptr，因此在生产环境中建议捕获或使用 if (auto sp = weak.lock()) 进行检查。

5. 性能考量

• 内存占用：shared_ptr 在对象头中额外存放计数指针，weak_ptr 只存放计数指针。若对象本身很小，weak_ptr 的开销更低。
• 计数操作：shared_ptr 的构造、析构和赋值会修改计数，若频繁操作，可能成为瓶颈。weak_ptr 只在 lock() 时检查计数，性能更好。
• 缓存友好性：使用 weak_ptr 可以减少共享所有权对象的数量，降低缓存未命中率。

6. 小结

• shared_ptr 用于需要共享所有权的场景，自动管理资源生命周期。
• weak_ptr 用于观察对象、打破循环引用或实现缓存。
• 通过合理组合使用，两者可以让 C++ 程序既安全又高效。

掌握这两者的细微差别，是写出稳健现代 C++ 代码的关键之一。

在 C++ 现代编程中，智能指针是管理动态内存的核心工具。标准库提供了两种最常用的智能指针：std::unique_ptr 和 std::shared_ptr。它们各自承担不同的职责，选择合适的指针能够既提高代码安全性，又保持性能。本文将从概念、内存管理、所有权语义、线程安全、以及典型使用场景等方面，对两者进行对比与说明，并给出实战建议。

1. 基本概念

指针	所有权类型	是否可复制	是否可移动
`std::unique_ptr
`	独占所有权	否	是
`std::shared_ptr
`	共享所有权	是	是

• 独占所有权：一个 unique_ptr 在同一时刻只能有一个拥有者，所有权转移只能通过 std::move 完成。
• 共享所有权：一个 shared_ptr 可以有多个指向同一对象的实例，内部维护引用计数，计数为 0 时自动销毁对象。

2. 内存管理

• unique_ptr：在作用域结束或显式 reset() 时，立即调用 delete 释放资源。无需额外的引用计数开销。
• shared_ptr：维护一个计数器（通常与对象一起存放在分配的块中）。每一次复制会增加计数，销毁时递减。计数为 0 时才销毁对象。

因此，unique_ptr 在单线程或确定唯一所有者的场景下性能更佳；shared_ptr 适合需要多处共享生命周期的情况，但需承担计数器的读写开销。

3. 所有权语义

• 移动语义：unique_ptr 必须移动才能转移所有权；shared_ptr 可以通过复制共享所有权。
• 不可复制：unique_ptr 禁止复制，以防止出现两份指针指向同一资源而导致双重删除。shared_ptr 允许复制，但内部同步引用计数，避免双删。

4. 线程安全

• unique_ptr：其析构过程不是线程安全的。若多个线程持有同一 unique_ptr，必须自己同步。
• shared_ptr：计数器的增减是线程安全的（使用原子操作）。但对象本身的状态不受保护，需要外部同步。

5. 典型使用场景

场景	推荐指针
单例/生命周期由创建者决定	unique_ptr
所有权转移（例如工厂返回对象）	unique_ptr
需要共享生命周期（如观察者模式、事件系统）	shared_ptr
对象需要在多线程间共享	shared_ptr + 外部锁或 std::atomic
管理数组	unique_ptr<T[]>（推荐）或 shared_ptr + 自定义删除器
与 C 风格 API 对接（需要裸指针或非所有权）	unique_ptr + std::weak_ptr 结合

6. 常见陷阱与建议

1. 循环引用
   shared_ptr 在存在循环引用（A->B, B->A）时会导致内存泄漏。使用 std::weak_ptr 破坏循环。

2. 性能评估
   shared_ptr 的引用计数是原子操作，导致多线程下的缓存失效。若不需要共享，尽量使用 unique_ptr。

3. 自定义删除器
   对于非 new 分配的资源（如文件句柄、网络 socket），可以在 unique_ptr 或 shared_ptr 中提供自定义删除器。

4. 不可用 make_shared 的场景
   make_shared 会把计数器和对象一起分配，减少一次内存分配。若需要 unique_ptr 或自定义删除器，则需手动 new。

5. 避免裸指针逃逸
   在公共接口中尽量返回 shared_ptr 或 unique_ptr，不要暴露裸指针。

7. 代码示例

// unique_ptr 示例
std::unique_ptr <MyClass> create()
{
    return std::make_unique <MyClass>();
}

// shared_ptr 示例
std::shared_ptr <MyClass> getShared()
{
    static std::weak_ptr <MyClass> cache;
    auto ptr = cache.lock();
    if (!ptr) {
        ptr = std::make_shared <MyClass>();
        cache = ptr;
    }
    return ptr;
}

在上述 create 函数中，所有权始终归于调用者；getShared 通过 weak_ptr 实现单例缓存，避免循环引用。

8. 结语

std::unique_ptr 与 std::shared_ptr 并不是互斥关系，而是根据所有权需求进行组合使用的工具。正确理解它们的所有权语义、性能特性和线程安全机制，能帮助开发者写出既安全又高效的 C++ 代码。随着 C++20/23 的继续演进，智能指针的使用已成为现代 C++ 编程的基础。祝你编码愉快！

协程（Coroutines）是一种轻量级的协作式多任务实现方式，能够让函数在执行过程中暂停并恢复，极大地简化异步编程和生成器的实现。自 C++20 起，标准库已经提供了协程支持，但在实际项目中，很多人仍然倾向于使用第三方协程库或自己实现微协程。本文将从语言特性、标准库实现、常见错误以及如何自行实现一个简单协程框架等方面进行详细解析。

---

1. C++20 协程的基本语法

C++20 引入了 co_await、co_yield、co_return 三个关键字，配合 std::future、std::generator 等类型实现协程。一个最小的协程示例：

#include <iostream>
#include <coroutine>
#include <thread>
#include <chrono>

struct Task {
    struct promise_type {
        Task get_return_object() { return {}; }
        std::suspend_never initial_suspend() { return {}; }
        std::suspend_never final_suspend() noexcept { return {}; }
        void unhandled_exception() { std::terminate(); }
        void return_void() {}
    };
};

Task simpleCoroutine() {
    std::cout << "Start\n";
    co_return;
}

int main() {
    simpleCoroutine();
    return 0;
}

此协程立即执行到结束，因为 initial_suspend 和 final_suspend 都返回 suspend_never。

---

2. 协程与传统异步模型的区别

传统异步	协程
需要回调函数	代码可读性高，像同步代码
线程/事件循环	轻量级协作
错误处理复杂	通过异常传播

协程的核心优势在于把“暂停点”显式化，消除了回调金字塔。

---

3. 常见错误与调试技巧

1. 忘记 co_return
   协程没有 co_return 会导致 main 返回未定义状态。
   调试技巧：使用编译器警告 -Wreturn-type。

2. 错误的 Promise 实现
   promise_type 的生命周期与协程的生命周期紧密相关。
   调试技巧：在 promise_type 构造和析构中打印日志。

3. 忘记 std::suspend_always/suspend_never
   让协程一直挂起或一直执行，导致无限循环。
   调试技巧：使用 std::suspend_always 作为默认暂停策略。

4. 栈溢出
   过深的递归协程会导致栈溢出。
   调试技巧：限制递归深度，或改用迭代。

---

4. 自己实现一个简易协程框架

虽然标准库提供了完整实现，但有时我们想要更细粒度的控制，例如自定义协程调度器。下面给出一个最小化协程框架的实现，支持 yield 与 await。

4.1 基础类型

#include <functional>
#include <vector>
#include <memory>

class Coroutine;

using Task = std::function<void(Coroutine&)>;

class Coroutine {
public:
    Coroutine(Task func) : func_(std::move(func)), finished_(false) {}

    void resume() {
        if (!finished_) func_(*this);
    }

    void yield() {
        // 暂停当前协程，控制权交给调度器
        // 这里简单实现直接返回
    }

    void finish() { finished_ = true; }

    bool finished() const { return finished_; }

private:
    Task func_;
    bool finished_;
};

4.2 调度器

class Scheduler {
public:
    void add(Coroutine::Task t) {
        coros_.emplace_back(std::make_shared <Coroutine>(std::move(t)));
    }

    void run() {
        while (!coros_.empty()) {
            auto c = coros_.front();
            c->resume();
            if (c->finished()) {
                coros_.erase(coros_.begin());
            }
        }
    }

private:
    std::vector<std::shared_ptr<Coroutine>> coros_;
};

4.3 示例：生成斐波那契数列

int main() {
    Scheduler sched;

    sched.add([](Coroutine& self) {
        int a = 0, b = 1;
        for (int i = 0; i < 10; ++i) {
            std::cout << a << " ";
            int next = a + b;
            a = b;
            b = next;
            self.yield();  // 暂停
        }
        self.finish();
    });

    sched.run();
}

该框架非常基础，缺少异常传播、状态保存、协程间通信等高级特性。但它展示了协程的核心概念：一个协程是一个可暂停、可恢复的执行单元，调度器负责管理其生命周期。

---

5. 进一步学习与实践

• Boost.Coroutine：成熟的协程库，支持多种调度策略。
• Libco：轻量级协程库，适合嵌入式或高并发场景。
• C++20 协程实验室：在现代 IDE 中尝试 co_await 与 co_yield。

实践建议：先在一个小项目中使用标准协程实现异步 IO，然后逐步尝试自己实现调度器，了解协程的底层机制。

---

6. 小结

C++20 的协程为异步编程提供了强大的工具。掌握 co_await、co_yield 的使用后，编写异步代码会像写同步代码一样自然。标准库提供的 std::generator、std::future 等类型已经足够满足大多数需求，但对细粒度控制有需求的项目，可以尝试自己实现轻量级协程框架。通过本文的代码示例与调试技巧，读者可以快速上手并深入理解协程的本质。

祝编码愉快，协程无极限！

在 C++20 中， 库为我们提供了大量新工具，其中最令人兴奋的是 std::ranges::views。这些视图（views）允许我们以惰性、链式的方式处理容器，而无需显式创建临时容器。下面让我们从几个常见的使用场景，逐步探索视图的优势与使用技巧。

1. 惰性求值与节省空间

传统的 STL 算法往往在中间需要生成临时容器。例如，筛选并平方一个整数序列：

std::vector <int> nums = {1,2,3,4,5,6,7,8,9,10};

std::vector <int> result;
for (auto x : nums) {
    if (x % 2 == 0) result.push_back(x * x);
}

如果你使用 std::ranges::views，可以写成：

using namespace std::ranges::views;
auto result = nums | filter([](int x){ return x % 2 == 0; }) 
                 | transform([](int x){ return x * x; });

这里 result 并不是一个 `vector

`，而是一个 *view* 对象，它在你真正需要访问元素时才会进行计算。若随后你只想打印前几个元素，仍能保持惰性： “`cpp for (auto x : result | take(3)) { std::cout #include #include #include #include std::vector words = {“apple”, “banana”, “cherry”, “date”, “elderberry”, “fig”, “grape”}; auto is_long = [](const std::string& s){ return s.size() > 5; }; auto to_upper = [](const std::string& s){ std::string r = s; std::transform(r.begin(), r.end(), r.begin(), ::toupper); return r; }; auto processed = words | std::ranges::views::filter(is_long) | std::ranges::views::transform(to_upper) | std::ranges::views::unique; // 去重（假设已经排序） for (auto&& word : processed) { std::cout v(20); std::iota(v.begin(), v.end(), 0); // 0..19 // 取中间 5 个元素 auto middle = std::ranges::subrange(v.begin() + 5, v.begin() + 10); auto sum = std::ranges::accumulate(middle, 0); “` 通过 `std::span`，你还能将裸指针转为安全的视图： “`cpp int arr[] = {10, 20, 30, 40, 50}; std::span s(arr, 5); // 视图，长度为 5 auto avg = std::ranges::accumulate(s, 0) / static_cast (s.size()); “` ### 4. 性能考量与实践建议 – **惰性 vs 立即**：默认视图是惰性的，适合链式调用和延迟计算。但如果你需要多次迭代同一序列，最好将视图转换为 `std::vector` 或 `std::array`，避免重复遍历。 – **记忆体占用**：视图本身占用极少空间，只有迭代器和闭包等小结构。但如果闭包捕获了大量数据，也会增加视图大小。 – **与 `std::algorithm` 的互补**：大多数传统算法已提供视图版本，例如 `std::ranges::find_if`。在需要更复杂的链式操作时，视图是最佳选择。 ### 5. 小结 C++20 的 `std::ranges::views` 为我们提供了一种更直观、模块化、内存友好的方式处理容器数据。通过惰性求值、链式组合以及与 `subrange`、`span` 的结合，你可以写出既简洁又高效的代码。熟练掌握这些工具后，日常的数据处理任务将变得异常轻松。 如果你还没有尝试过 `std::ranges::views`，不妨把一个现有的项目迁移到视图风格，亲身感受它带来的乐趣与便利。祝编码愉快！

在 C++20 之前，constexpr 用来声明在编译期可求值的函数和变量，而在 C++20 引入了 consteval，它的作用更为严格。下面从语义、使用场景、性能以及编译错误处理几个方面，详细阐述两者的区别与联系。

1. 语义定义

   • constexpr：声明的实体在编译期可以求值，但并不强制要求一定在编译期计算。若编译器决定在运行期计算，则仍然满足约束。
   • consteval：声明的实体必须在编译期求值，编译器如果无法在编译期求值，则报错。它保证了完全的编译期执行。

2. 函数返回值

   • constexpr 函数可以在编译期或运行期返回值。若在编译期调用，返回值为编译期常量；若在运行期调用，则返回值为运行时值。
   • consteval 函数只能在编译期调用。若在运行期调用，编译器会报错。

3. 参数与返回类型

   • constexpr 函数的参数可以是普通的 const 或者非 const，只要满足编译期可求值的条件。
   • consteval 函数的参数和返回值必须满足 constexpr 的约束，并且函数体内不允许使用任何可能导致运行期求值的操作（如非 constexpr 的库调用、递归深度超限等）。

4. 性能与优化

   • constexpr 允许编译器在需要时进行编译期优化，但在某些情况下会退回到运行期执行，导致潜在的运行时开销。
   • consteval 明确强制编译期求值，避免了运行时成本，适用于对性能有极端要求的场景（如生成编译期常量表、元编程库等）。

5. 编译错误与诊断

   • 使用 constexpr 时，如果在编译期无法求值，编译器会给出警告或错误信息，但仍会尝试在运行期执行。
   • 使用 consteval 时，一旦在编译期无法求值，编译器立即报错并停止编译，提示 “function must be a constexpr function and must be evaluated at compile time”。

6. 典型使用场景

   • constexpr：实现编译期计算的工具函数（如 constexpr int factorial(int n)），在运行时也可能调用。
   • consteval：生成唯一编译期 ID、构建编译期哈希表、实现编译期 JSON 解析等场景，确保函数调用在编译期完成。

7. 与 constinit 的关系

   • constinit 用于保证全局或命名空间作用域变量在编译期初始化，但不涉及函数。它常与 constexpr 结合使用，例如 constinit int size = compute_size();，其中 compute_size 必须是 constexpr 或 consteval。

8. 代码示例

// constexpr 示例
constexpr int add(int a, int b) {
    return a + b;
}
int main() {
    constexpr int x = add(2, 3); // 编译期求值
    int y = add(4, 5);           // 运行期求值
}

// consteval 示例
consteval int fib(int n) {
    return n <= 1 ? n : fib(n - 1) + fib(n - 2);
}
int main() {
    constexpr int f10 = fib(10); // 必须在编译期求值
    // int f20 = fib(20);        // 编译错误：不能在运行期调用 consteval 函数
}

9. 未来展望
   C++ 标准委员会正考虑进一步扩展 consteval 的功能，例如支持更复杂的递归和模板元编程模式，以满足更高性能编译期计算需求。

总结：constexpr 提供了灵活的编译期/运行期双重可求值特性，而 consteval 则强制执行编译期求值，适用于对性能极度敏感或需确保编译期不变性的场景。两者在现代 C++ 中都是不可或缺的工具，合理选用可以大幅提升程序的安全性和执行效率。

C++17 中的 constexpr 已经彻底改变了我们编写编译期计算的方式。过去，constexpr 只能用来描述单行常量表达式，受限于函数返回值只能是字面量、构造函数和条件运算符。然而在 C++17 之后，constexpr 函数可以包含多条语句、循环、条件分支、甚至异常处理。通过这些改进，编译器在编译期可以执行更复杂的计算，从而极大提升程序运行时性能。

1. constexpr 的核心扩展

• 多行语句：constexpr 函数现在可以包含 {} 块和多条语句。
• 循环与条件：for, while, if 等语句被允许在 constexpr 函数内部。
• 异常：编译期可以抛出异常，但必须在运行时被捕获。
• 类成员：支持 constexpr 构造函数、成员函数以及静态数据成员。

这些改动意味着我们可以把之前只能在运行时执行的算法搬到编译期，例如快速排序、斐波那契数列、字符串解析等。

2. 常见使用场景

2.1 编译期字符串处理

constexpr std::size_t strlen_c(const char* str) {
    std::size_t len = 0;
    while (str[len] != '\0') ++len;
    return len;
}

使用 strlen_c 可以在编译期得到字符串长度，从而为模板参数提供常量。

2.2 生成编译期查找表

template<std::size_t N>
constexpr std::array<int, N> make_lookup_table() {
    std::array<int, N> table{};
    for (std::size_t i = 0; i < N; ++i)
        table[i] = static_cast <int>(i * i);
    return table;
}

该函数在编译期生成平方表，避免运行时循环。

2.3 运行时性能提升

假设有一个函数需要根据输入返回固定值列表中的第 n 个值。若使用 constexpr 编译期生成该列表，程序在运行时直接索引，避免多次计算。

3. 编译器支持与限制

• GCC 7+ / Clang 5+ / MSVC 2017+ 支持 C++17 constexpr 扩展。
• 递归深度：编译器对 constexpr 递归的深度有限制，典型值为 1024。
• 异常：在编译期抛出的异常会导致编译错误，除非被捕获。

4. 与 consteval 的区别

C++20 引入了 consteval，它强制函数在编译期执行，任何未能在编译期完成的调用都会导致编译错误。相比之下，constexpr 仍可在运行时执行。利用 consteval 可以进一步保证编译期计算的完整性。

5. 小结

C++17 对 constexpr 的扩展使得编译期计算不再局限于简单表达式，而是可以处理复杂算法和数据结构。合理运用这些特性，可以显著降低运行时负担，提高程序整体效率。建议在项目初期就评估哪些部分可以迁移至编译期，并借助现代编译器持续优化。

---

实战建议：先在项目中挑选可量化性能的热点代码，将其重构为 constexpr，然后使用 static_assert 验证编译期结果。通过编译日志查看是否真正被编译期执行，确保得到期望的性能提升。

在C++20中，协程（coroutine）为异步编程提供了语言级支持。co_await、co_yield和co_return让我们能够像编写同步代码一样写出异步逻辑。本文将演示如何在网络I/O中使用协程，并解释背后的关键概念。

1. 基本概念

• promise_type：每个协程都有一个关联的promise_type，它负责创建协程句柄、存储返回值、处理异常等。
• awaitable：实现await_ready(), await_suspend(), await_resume()接口的对象，表示可以被co_await的对象。
• co_await：在执行到co_await时，协程会挂起，直到awaitable完成。

2. 简单示例：文件读取

假设我们有一个异步文件读取接口async_read_file，返回一个awaitable<std::string>。下面是一个使用协程读取文件并打印内容的例子：

#include <iostream>
#include <string>
#include <future>
#include <thread>
#include <chrono>

struct AwaitableRead {
    std::string file_path;
    std::promise<std::string> prom;

    AwaitableRead(const std::string& path) : file_path(path) {}

    bool await_ready() noexcept { return false; }

    void await_suspend(std::coroutine_handle<> h) {
        // 异步读取模拟：在后台线程读取文件
        std::thread([this, h]() {
            std::this_thread::sleep_for(std::chrono::milliseconds(100)); // 模拟延迟
            // 这里可以放置真正的文件读取逻辑
            prom.set_value("文件内容：" + file_path);
            h.resume(); // 恢复协程
        }).detach();
    }

    std::string await_resume() { return prom.get_future().get(); }
};

AwaitableRead async_read_file(const std::string& path) {
    return AwaitableRead(path);
}

auto read_and_print() -> std::future <void> {
    std::string content = co_await async_read_file("example.txt");
    std::cout << content << std::endl;
}

3. 处理异常

如果读取过程中抛出异常，可以在await_suspend里捕获并传递给promise：

void await_suspend(std::coroutine_handle<> h) {
    std::thread([this, h]() {
        try {
            std::this_thread::sleep_for(std::chrono::milliseconds(100));
            // 假设读取失败
            throw std::runtime_error("读取错误");
            prom.set_value("...");
        } catch (...) {
            prom.set_exception(std::current_exception());
        }
        h.resume();
    }).detach();
}

4. 与std::future的整合

C++20标准库提供std::future与协程的交互方式。我们可以用co_return返回值给std::future：

auto async_operation() -> std::future <int> {
    co_return 42; // 直接返回给future
}

5. 性能考虑

• 协程的状态机生成开销很小，通常不超过几十字节。
• await_suspend与await_resume的调用链会产生函数调用开销，但相较于传统回调式，简洁且易于维护。
• 需要注意：如果在协程中使用阻塞操作，会导致线程阻塞，失去协程非阻塞的优势。

6. 总结

C++20协程通过co_await简化了异步代码的书写，使得异步逻辑与同步代码保持一致。通过自定义awaitable对象，可以将任何异步操作（如网络、文件、定时器）包装成协程接口。掌握这些核心概念后，你就可以在现代C++项目中轻松实现高性能、可维护的异步系统。

祝你编码愉快，C++协程之旅顺利开启！