C++

OpenSSL RAND_bytes 完整原理 从操作系统的硬件中断到你代码里的 16 字节 Session ID，随机数经历了什么？ 一、为什么需要密码学安全随机数 1.1 一个真实的安全问题 Hical 框架 v1.0.0 的 Session ID 生成： 1 2 3 4 5 6 // v1.0.0（已修复） thread_local std::mt19937_64 rng(std::random_device{}()); std::uniform_int_distribution<uint64_t> dist; uint64_t hi = dist(rng); uint64_t lo = dist(rng); // 拼成 128 位十六进制 Session ID 看起来安全？不安全。 mt19937_64 是梅森旋转算法，一个确定性伪随机数生成器。攻击者只需收集 312 个连续的 64 位输出（约 156 个 Session ID），就能完全重建内部状态，预测此后所有 Session ID。 v2.0.0 的修复： 1 2 3 // v2.0.0 unsigned char buf[16]; RAND_bytes(buf, sizeof(buf)); // OpenSSL 密码学安全随机数 RAND_bytes 基于 AES-256 加密算法，即使攻击者收集到数十亿个输出，也无法预测下一个。 1.2 伪随机 vs 密码学安全随机 维度 伪随机（PRNG） 密码学安全（CSPRNG） 代表 mt19937、rand()、线性同余 RAND_bytes、getrandom(2) 内部状态 可从输出反推 不可从输出反推 前向安全 无（知道当前状态可反推历史） 有（每次输出后更新状态，旧状态不可恢复） 适用场景 模拟、游戏随机、统计抽样 密钥、Session ID、Token、Nonce 性能 ~3ns/64bit ~15ns/16bytes 标准 无 NIST SP 800-90A 判断标准：如果输出泄露后会造成安全影响（Session 劫持、密钥泄露），就必须用 CSPRNG。 ...

C++26 前瞻心得：下一代 C++ 最值得期待的特性 C++11 让 C++ 进入现代，C++20 让 C++ 追上时代，C++26 要让 C++ 重新定义「零开销抽象」的边界。 写在前面 C++26 标准预计 2026 年底正式发布。截至本文写作时（2026 年 5 月），核心特性已基本锁定，部分编译器开始提供实验性支持。 这篇文章不追求完整列举所有提案，只聊我认为对实际项目冲击最大的特性——尤其从游戏服务器和 Hical 框架开发的角度。这是 C++17 心得 和 C++20 心得 的续篇。 声明：部分特性的最终语法可能随标准定稿而调整，代码示例基于当前最新提案。 一、静态反射（Static Reflection）—— C++ 的 Game Changer 1.1 为什么反射是最重要的 C++26 特性 在 Java、C#、Go 中习以为常的操作——遍历结构体字段、获取类名、自动序列化——在 C++ 中一直只能靠宏或代码生成。C++26 的反射（P2996）让编译器在编译期暴露类型的元信息： 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 #include <meta> struct Player { uint64_t id; std::string name; int level; int64_t gold; }; // 编译期遍历所有成员 template <typename T> void printFields(const T& obj) { template for (constexpr auto member : std::meta::members_of(^T)) { if constexpr (std::meta::is_nonstatic_data_member(member)) { std::println(" {}: {}", std::meta::name_of(member), obj.[:member:]); } } } Player p{1001, "Hical", 85, 999999}; printFields(p); // 输出: // id: 1001 // name: Hical // level: 85 // gold: 999999 零运行时开销，不需要宏，不需要代码生成工具，编译器原生支持。 ...

C++20 实战心得：现代 C++ 真正成熟的一代 C++11 是革命，C++17 是打磨，C++20 是让 C++ 终于像一门「现代语言」。 写在前面 如果说 C++17 的升级是务实的，那 C++20 就是一次结构性的飞跃。协程、Concepts、Ranges、Modules——每一个都是重量级特性。但老实说，截至 2026 年，并非所有特性都已经在生产环境中稳定好用。 这篇文章从我在游戏服务器和 Hical 框架开发中的实际使用出发，聊聊哪些 C++20 特性已经值得用、哪些还需要等等。 一、Concepts —— 模板错误信息终于能看懂了 1.1 C++20 之前的模板报错 先感受一下 C++17 时代的"恐怖"： 1 2 std::list<int> lst; std::sort(lst.begin(), lst.end()); GCC 会喷出几十行模板展开错误，核心意思是 std::list::iterator 不是随机访问迭代器——但你得从一堆 __normal_iterator、__gnu_cxx 嵌套模板中自己悟出来。 1.2 Concepts：把约束说人话 1 2 3 4 5 6 7 8 9 template <std::random_access_iterator Iter> void mySort(Iter first, Iter last) { // ... } std::list<int> lst; mySort(lst.begin(), lst.end()); // 错误信息：约束 'random_access_iterator' 不满足 // 一行，清清楚楚 Concepts 的本质：给模板参数加上编译期的「类型契约」。SFINAE 能做的它都能做，但写法是人能读懂的。 ...

C++17 实战心得：那些真正改变我写代码方式的特性 从游戏服务器开发的视角出发，不求面面俱到，只聊那些真正让我「回不去了」的 C++17 特性。 写在前面 C++17 的特性列表很长，但实际工作中高频使用的并不多。这篇文章只聊我在游戏服务器开发中真正用上了、且明显感到提升的特性，按「爽度」排序。 一、结构化绑定（Structured Bindings） 1.1 告别 .first / .second C++17 之前，遍历 std::map 是这样的： 1 2 3 4 5 for (auto it = playerMap.begin(); it != playerMap.end(); ++it) { auto playerId = it->first; auto& player = it->second; // ... } C++17 之后： 1 2 3 for (auto& [playerId, player] : playerMap) { LOG_DEBUG << "玩家 " << playerId << " 等级: " << player.level; } 一行搞定，变量名直接表达语义，可读性提升巨大。 1.2 配合 insert / emplace 的返回值 1 2 3 4 auto [iter, success] = onlinePlayers.emplace(playerId, std::move(session)); if (!success) { LOG_WARN << "玩家 " << playerId << " 重复登录"; } 比起 result.second 去判断是否插入成功，success 的语义一目了然。 1.3 多返回值函数 1 2 // 解析网络包头：返回包类型和包体长度 auto [msgType, bodyLen] = parsePacketHeader(buffer); 不用再纠结「该用 std::pair 还是定义一个临时结构体」的问题了。当然，如果返回值超过 3 个，还是老老实实定义结构体。 ...

深入学习 C++26 静态反射（Static Reflection） 提案：P2996R9（Reflection for C++26） 头文件：<meta> 命名空间：std::meta 编译器支持：Clang（P2996 实验分支）、EDG（部分）/ GCC 和 MSVC 计划中 注意：C++26 标准预计 2026 年底定稿，本文语法基于当前最新提案，最终可能有微调 一、为什么需要静态反射？ 1.1 C++ 元编程的历史痛点 C++ 一直以"零开销抽象"著称，但在类型自省这件事上，四十年来只能靠旁门左道： 方案 A：宏暴力展开 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 // 用宏定义可序列化结构体 #define DEFINE_FIELDS(TYPE, ...) \ static constexpr auto fields() { \ return std::make_tuple(__VA_ARGS__); \ } struct Player { uint64_t id; std::string name; int level; int64_t gold; DEFINE_FIELDS(Player, FIELD(id), FIELD(name), FIELD(level), FIELD(gold) // 手动列举每个字段 ) }; 方案 B：代码生成工具（protobuf / flatbuffers / 自研工具） ...

深入学习 C++20 协程（Coroutines） 头文件：<coroutine> 命名空间：std 编译器要求：GCC 11+ / Clang 14+ / MSVC 19.28+（均需 -std=c++20 或以上） 注意：GCC 10 / Clang 8~13 可通过 -fcoroutines 和 <experimental/coroutine> 使用实验性支持 一、为什么需要协程？ 1.1 异步编程的传统痛点 游戏服务器中充斥着异步操作——数据库查询、网络 I/O、定时器回调。传统方案各有各的痛： 方案 A：回调地狱（Callback Hell） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 void HandleLogin(Connection* conn, const LoginPacket& pkt) { // 第1步：查询数据库验证账号 dbManager->QueryAsync("SELECT * FROM accounts WHERE name=?", pkt.name, [conn, pkt](const DBResult& result) { if (!result.ok) { conn->SendError("DB错误"); return; } // 第2步：查询角色列表 dbManager->QueryAsync("SELECT * FROM characters WHERE account_id=?", result.accountId, [conn](const DBResult& charResult) { if (!charResult.ok) { conn->SendError("DB错误"); return; } // 第3步：加载角色数据 dbManager->QueryAsync("SELECT * FROM inventory WHERE char_id=?", charResult.charId, [conn, charResult](const DBResult& invResult) { // 第4步：终于可以发送登录成功了... conn->SendLoginSuccess(charResult, invResult); }); }); }); } 方案 B：状态机（State Machine） ...

深入学习 C++17 PMR（Polymorphic Memory Resource） 头文件：<memory_resource> 命名空间：std::pmr 编译器要求：GCC 9+ / Clang 9+ / MSVC 19.13+（均需 -std=c++17 或以上） 一、为什么需要 PMR？ 1.1 传统 Allocator 模型的痛点 C++98 引入的 Allocator 是模板参数，这意味着： 1 2 3 4 std::vector<int, MyAlloc<int>> vec1; std::vector<int, std::allocator<int>> vec2; // vec1 和 vec2 是不同类型！无法互相赋值、放进同一个容器 核心问题： 痛点 说明 类型传染 Allocator 是模板参数，换一个 Allocator 就变了类型，所有接口签名都要跟着改 无法运行时切换 编译期绑定，测试时想换成 debug allocator？重新编译 难以组合 想让 vector 内部的 string 也用同一个 arena？极其繁琐 状态传播困难 有状态 allocator（如持有内存池指针）在容器拷贝/移动时语义复杂 1.2 PMR 的解法：运行时多态 PMR 用一个虚基类 std::pmr::memory_resource 取代模板参数，容器统一使用 std::pmr::polymorphic_allocator<T>： ...

系列导航：入门篇 | 进阶篇 | 实战篇 前置知识 已阅读入门篇和进阶篇，掌握 io_uring 双环形缓冲区和 liburing API 了解 C++20 协程基础（co_await、coroutine_handle、promise_type） 建议先阅读 深入学习 Boost.Asio（三）：实战篇 中的协程部分作为对照 1. RAII 封装：安全管理 io_uring 资源 1.1 为什么需要 C++ 封装 直接使用 liburing 的 C API 有三个痛点： io_uring_queue_init / io_uring_queue_exit 手动配对，容易遗漏 user_data 是 void* 或 uint64_t，类型安全全靠人肉 提交→收割的事件循环代码高度模板化，每个项目重写一遍 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 封装层次： 应用代码（协程/回调） │ ▼ ┌──────────────────────┐ │ IoUringAwaitable │ ← 协程集成层（co_await 一个 I/O 操作） └──────────────────────┘ │ ▼ ┌──────────────────────┐ │ IoUringContext │ ← 事件循环层（submit / wait / dispatch） └──────────────────────┘ │ ▼ ┌──────────────────────┐ │ IoUring (RAII) │ ← 资源管理层（init / exit） └──────────────────────┘ │ ▼ liburing C API 1.2 IoUring：RAII 包装 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 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 // IoUring.hpp — RAII 封装 io_uring 实例 // 编译：g++ -std=c++20 -O2 xxx.cpp -luring -o xxx #pragma once #include <liburing.h> #include <stdexcept> #include <string> #include <cstring> class IoUring { public: // 构造时初始化 io_uring，指定 SQ 大小和可选标志 explicit IoUring(unsigned entries, unsigned flags = 0) { int ret = io_uring_queue_init(entries, &ring_, flags); if (ret < 0) { throw std::runtime_error( "io_uring_queue_init 失败: " + std::string(strerror(-ret))); } } // 禁止拷贝（io_uring 资源不可共享） IoUring(const IoUring&) = delete; IoUring& operator=(const IoUring&) = delete; // 允许移动 IoUring(IoUring&& other) noexcept : ring_(other.ring_) { other.moved_ = true; } // 析构时自动清理 ~IoUring() { if (!moved_) { io_uring_queue_exit(&ring_); } } // 获取 SQE（SQ 满时自动 submit 腾出空间） io_uring_sqe* getSqe() { io_uring_sqe* sqe = io_uring_get_sqe(&ring_); if (!sqe) { // SQ 满了，先提交当前积压的请求 io_uring_submit(&ring_); sqe = io_uring_get_sqe(&ring_); if (!sqe) { throw std::runtime_error("SQ 空间不足，即使 submit 后仍无法获取 SQE"); } } return sqe; } int submit() { return io_uring_submit(&ring_); } // 阻塞等待至少一个 CQE io_uring_cqe* waitCqe() { io_uring_cqe* cqe = nullptr; int ret = io_uring_wait_cqe(&ring_, &cqe); if (ret < 0) { throw std::runtime_error( "io_uring_wait_cqe 失败: " + std::string(strerror(-ret))); } return cqe; } // 非阻塞查看 CQE io_uring_cqe* peekCqe() { io_uring_cqe* cqe = nullptr; int ret = io_uring_peek_cqe(&ring_, &cqe); if (ret == -EAGAIN) return nullptr; // 无就绪 CQE if (ret < 0) { throw std::runtime_error( "io_uring_peek_cqe 失败: " + std::string(strerror(-ret))); } return cqe; } // 标记 CQE 已消费 void seenCqe(io_uring_cqe* cqe) { io_uring_cqe_seen(&ring_, cqe); } // 访问底层 io_uring（高级用法需要） io_uring* raw() { return &ring_; } private: io_uring ring_{}; bool moved_ = false; }; 设计原则：RAII 保证 io_uring_queue_exit 一定被调用，即使异常传播也不会泄漏内核资源。getSqe() 中自动 submit 是防御性编程——避免 SQ 满导致的隐性 bug。 ...

系列导航：入门篇 | 进阶篇 | 实战篇 前置知识 已阅读入门篇，理解 SQ/CQ 双环形缓冲区和 liburing 基本 API 熟悉 TCP socket 编程基础（socket、bind、listen、accept） 1. SQPOLL：零系统调用提交 1.1 常规模式的瓶颈 入门篇中每次 io_uring_submit() 底层都会调用 io_uring_enter() 系统调用： 1 2 3 4 5 6 7 8 9 10 常规模式： 用户态 内核态 │ │ │ SQE 写入共享内存 │ │ │ │ io_uring_enter(to_submit=N) │ ├────────系统调用──────────────→│ ← 仍有上下文切换 │ │ 读取 SQ，执行 I/O │ 返回 │ │←─────────────────────────────┤ 对于超高频提交场景（如高频交易、高吞吐数据库），连这一次系统调用都嫌多。 ...

系列导航：入门篇 | 进阶篇 | 实战篇 引言：epoll 之后，还能更快吗？ 假设你用 epoll 写了一个高并发 TCP 服务器，性能已经不错——C10K 问题解决了。但当你把连接数推到 C1M（百万级） 时： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 epoll 的瓶颈： 用户态 内核态 │ │ │ epoll_wait() │ ├───────系统调用─────────────→│ ← 每次至少一次上下文切换 │ │ │ 返回就绪的 fd 列表 │ │←───────────────────────────┤ │ │ │ recv(fd_1, buf, ...) │ ├───────系统调用─────────────→│ ← 每个 fd 又一次系统调用！ │ │ │ send(fd_1, resp, ...) │ ├───────系统调用─────────────→│ ← 再一次！ │ │ │ recv(fd_2, buf, ...) │ ├───────系统调用─────────────→│ ← N 个连接 = 2N+ 次系统调用 问题：epoll 只解决了"哪些 fd 就绪"的问题，每次 I/O 操作仍然需要独立的系统调用。百万连接下，系统调用的开销成为主要瓶颈——上下文切换、数据拷贝、内核锁竞争。 ...