C++17

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++ Web 框架设计三层 PMR 内存池：从原理到实战 本文以 Hical 框架为例，深入讲解如何利用 C++17 PMR（Polymorphic Memory Resource）为高并发 Web 服务器构建三层内存池架构。 为什么 Web 服务器需要自定义内存管理？ 一个 HTTP 请求的生命周期中，框架需要分配大量临时对象：解析缓冲区、路径字符串、JSON 值、响应体。在高并发场景下（如 50K QPS），new/delete 的全局锁竞争会成为显著瓶颈： 1 2 3 50,000 请求/秒 × 每请求 ~20 次分配 = 1,000,000 次/秒 new/delete ↓ 全局堆锁竞争 → CPU 空转 传统方案是自研内存池，但 C++17 提供了标准化的解决方案 —— PMR。 PMR 速览 PMR 的核心思想：把内存分配策略从容器类型中解耦。 1 2 3 4 5 // 传统方式：分配器绑定在类型中 std::vector<int> vec; // 永远用 std::allocator // PMR 方式：运行时切换分配策略 std::pmr::vector<int> vec(&myPool); // 用自定义内存池 标准库提供了三种现成的内存资源： ...

用 if constexpr + 模板在一份代码中同时处理 TCP 和 SSL 连接 本文以 Hical 框架的 GenericConnection 为例，展示如何用 C++17 的 if constexpr + 类型萃取在一个模板类中统一 TCP 和 SSL 两种连接，实现编译期零开销分支。 问题：TCP 和 SSL 的代码高度相似 TCP 连接和 SSL 连接的区别只有三处： socket 类型不同：tcp::socket vs ssl::stream<tcp::socket> 连接建立多一步 TLS 握手 关闭多一步 ssl::stream::async_shutdown 其余 99% 的代码——读循环、写循环、缓冲区管理、回调触发、状态机——完全相同。 传统方案：继承 + 虚函数 1 2 3 4 5 6 7 8 9 class TcpConnection : public Connection { tcp::socket socket_; void doRead() override { ... } }; class SslConnection : public Connection { ssl::stream<tcp::socket> socket_; void doRead() override { ... } // 几乎一样的代码 }; 问题： 两个类 90% 的代码重复 每次调用 doRead/doWrite 都经过虚函数表间接调用 修改共同逻辑需要同步两处 Hical 方案：一个模板统一 1 2 3 4 5 6 7 8 9 template <typename SocketType> class GenericConnection : public TcpConnection { SocketType socket_; // 一份读循环、一份写循环、一份状态机 // 差异部分用 if constexpr 处理 }; using PlainConnection = GenericConnection<tcp::socket>; using SslConnection = GenericConnection<ssl::stream<tcp::socket>>; 核心技术：类型萃取 + if constexpr 类型萃取：编译期判断 socket 类型 1 2 3 4 5 6 7 8 template <typename T> struct IsSslStream : std::false_type {}; template <typename T> struct IsSslStream<boost::asio::ssl::stream<T>> : std::true_type {}; template <typename T> inline constexpr bool hIsSslStream = IsSslStream<T>::value; 这是一个经典的模板特化技巧： ...

深入学习 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>： ...