AI 技能AI 插件人工智能【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills点击查看免费下载本指南聚焦 Boost.Asio及 standalone Asio在C11–17 工具链下的异步编程方案解决没有co_await就不能优雅地写异步网络代码这一核心痛点。内容以仓库中 pre-cpp20.md 为骨架结合 SKILL.md 的版本底线与易错规则展开。读完你将掌握如何在 C11 下用completion handlers回调与stackful coroutinesasio::spawnyield_context写出与 C20 协程风格等价的全双工、带超时、带帧协议的网络代码并正确配置 CMake 构建。为什么还需要 Pre-C20 风格C20 的co_await让异步代码变得像同步代码一样可读但现实是大量生产环境的工具链仍是 C11/14/17尤其是长期发行版例如 Debian bookworm 内置 Boost 1.74不支持awaitable_operators.hpp头文件。正如 SKILL.md 所强调的Asio 的 API 形态经历了三次演进classicio_service→io_context→ C20 coroutines同一个任务在三种工具链上有三种正确答案必须先确认目标 Boost 版本与 C 标准再选择对应的编码风格。关键认知是不能使用co_await时同一套 Asio 库现代 Boost 或 standalone Asio依然可用改变的只是异步风格的写法。io_context、make_strand、bind_executor、steady_timer、ssl::stream、signal_set、async_read/async_write/async_read_until、缓冲区和resolver都是库特性而非语言特性在协程风格与回调风格中完全一致可直接按 coroutines.md 中的用法使用。Pre-C20 有两种主流风格Completion handlers回调header-only、C11 起可用、无额外依赖是推荐的基准方案Stackful coroutinesasio::spawnyield_context写法像co_await但构建在 Boost.Coroutine/Boost.Context 之上必须链接非 header-only详见下文构建差异。C20 → Pre-C20 特性映射在 C11–17 环境下以下 C20 专属机制不可用co_await/awaitableT、co_spawn、use_awaitable、||/的awaitable_operators、as_tuple与co_composed。原文档pre-cpp20.md 中 C20 → pre-C20 mapping 一节给出了完整的等价映射表C20 协程Pre-C20 等价写法co_await op(use_awaitable)回调op(handler)· stackfulop(yield)awaitableT函数成员do_x()回调链 · 或spawn(strand, fn)co_spawn(ex, coro, tok)启动回调链 · 或asio::spawn(ex, fn, tok)as_tuple(use_awaitable)→[ec,n]回调的(ec, n)参数 · stackfulop(yield[ec])a() \|\| b()先完成者胜出一个看门狗定时器关闭 socket另一操作以operation_aborted失败a() b()等待两者完成同时启动两者在共享shared_ptrint中计数完成次数co_composed自定义操作asio::async_composeC11co_await this_coro::executorsocket_.get_executor()/ 传入的 executor理解这张表的关键在于||与不是语言特性而是协程风格的表达便利在回调世界中没有并发的语法糖只能靠定时器、共享计数和组合操作手工编排并发语义。回调风格全双工 写队列回调风格下全双工的写队列规则与协程风格完全一致——单靠 strand 并不能阻止交错写入必须用队列 在途标志强制同一时刻最多只有一个async_write。区别只在于用链式 handler 表达。同时必须在每一个 handler中捕获self shared_from_this()以保持连接存活pre-cpp20.md 中的核心示例class connection : public std::enable_shared_from_thisconnection { tcp::socket socket_; asio::strandasio::any_io_executor strand_; // tcp::sockets executor is any_io_executor std::dequestd::string outbox_; bool writing_ false; char buf_[1024]; public: explicit connection(tcp::socket s) : socket_(std::move(s)), strand_(asio::make_strand(socket_.get_executor())) {} void start() { do_read(); } void send(std::string frame) { // call on the strand only outbox_.push_back(std::move(frame)); if (!writing_) do_write(); } private: void do_read() { auto self shared_from_this(); socket_.async_read_some(asio::buffer(buf_), asio::bind_executor(strand_, // serialize handler execution this, self { if (ec) return; // self drops here → socket closes /* parse buf_[0..n]; call send() for replies */ do_read(); })); } void do_write() { // at most one async_write in flight writing_ true; auto self shared_from_this(); asio::async_write(socket_, asio::buffer(outbox_.front()), asio::bind_executor(strand_, this, self { if (ec) { writing_ false; return; } outbox_.pop_front(); if (!outbox_.empty()) do_write(); else writing_ false; })); } };这段代码同时印证了 SKILL.md 中最容易出错的三条规则strand 不序列化写入strand 序列化的是 handler 的执行不是整个组合操作的字节流。同一 strand 上两个在途的async_write仍会在线路上交错字节。全双工场景读循环 并发推送/应答需要每连接一个 strand并且一个带在途标志的出站队列缓冲区不拥有内存asio::buffer()只是视图底层存储必须存活到异步操作结束。回调风格下这些数据必须是成员变量而非函数局部变量连接必须比其 handler 存活更久enable_shared_from_this 在每个 handler /co_spawn中捕获self。Stackful 风格spawn yield_contextyield本身是一个完成令牌completion tokenop(socket, ..., yield)会挂起直到操作完成并返回结果错误默认抛出异常也可用yield[ec]将其转为error_code。每条链应运行在每连接专属的 strand 上pre-cpp20.mdasio::spawn(strand, // executor or strand self { // capture self for lifetime try { char data[1024]; for (;;) { std::size_t n self-socket_.async_read_some(asio::buffer(data), yield); asio::async_write(self-socket_, asio::buffer(data, n), yield); } } catch (const std::exception) { self-socket_.close(); } }, asio::detached); // completion token (3rd arg)注意事项错误处理策略默认抛boost::system::system_error对应 C20 风格默认行为yield[ec]不抛异常显式检查ec语义上等价于as_tuple(use_awaitable)生命周期lambda 必须捕获self与回调风格同样遵循连接存活于所有异步链原则第三个参数是完成令牌asio::detached表示不关心协程的结果三参数形式spawn(ex, fn, token)需要Boost ≥ 1.80旧版 Boost 只有两参数spawn(ex, fn)——这正是下文构建差异的关键点。无||的超时实现看门狗定时器C20 风格里read || timer一行就能实现读超时竞争。Pre-C20 下没有这个语法糖需要用独立的看门狗定时器替代每次读到数据就重置定时器第二条链等待定时器并在到期时关闭 socket从而让在途的读操作以operation_aborted失败pre-cpp20.md// callback watchdog void arm_timeout() { timer_.expires_after(std::chrono::seconds(30)); auto self shared_from_this(); timer_.async_wait(asio::bind_executor(strand_, this, self { if (!ec) socket_.close(); // fired → drop; reset cancels with ec })); } // call arm_timeout() again on every frame received to re-arm两个容易踩坑的细节重置定时器会让在途的async_wait以operation_aborted完成——在空闲超时循环中这是继续等待的信号不是错误SKILL.md 的 Step 3 明确列出此规则真正的到期才以无错误代码完成并关闭 socket超时关闭 socket 使另一条链上的读操作收到operation_aborted即实现了||的取消语义——这正是映射表中 first-wins race 的落地方案。回调风格的多步读与周期性伴随任务生命周期转移协程局部变量 → 成员变量这是回调风格最核心的心智转换协程风格里co_await挂起时栈帧仍存活局部缓冲区安全回调风格里handler 运行在异步操作完成之后此时函数局部变量早已析构因此头部/正文缓冲区必须成为成员变量否则就是悬垂引用dangling。同时遵循帧协议必须用组合读的规则——async_read恰好填满缓冲区而async_read_some可能短读pre-cpp20.md// members, NOT locals — they must survive until the handler runs uint32_t len_be_; std::string body_; static constexpr std::uint32_t max_frame_size 1U 20; // protocol limit: 1 MiB void read_frame() { auto self shared_from_this(); asio::async_read(socket_, asio::buffer(len_be_, sizeof len_be_), asio::bind_executor(strand_, this, self { if (ec) return; const std::uint32_t frame_length ntohl(len_be_); if (frame_length max_frame_size) { boost::system::error_code ignored; socket_.close(ignored); // reject before allocation return; } body_.assign(static_caststd::size_t(frame_length), \0); asio::async_read(socket_, asio::buffer(body_), // read exactly N bytes asio::bind_executor(strand_, this, self { if (ec2) return; handle_frame(body_); // dispatch on type byte read_frame(); // next frame })); })); }这里的max_frame_size上限是安全关键点长度前缀来自不可信对端先校验长度再分配内存否则std::string(n, \0)的 n 被攻击者控制会成为内存耗尽向量SKILL.md 的 Security Safety Notes 明确提示。socket_.close(ignored)在分配前拒绝超限帧正是防御性编程的正确顺序。周期性伴随任务自重新调度定时器协程风格中一个 detached 的伴随协程可以靠标志位或cancellation_signal停止回调风格中没有可停止的 detached 协程做法是自重新调度self-rescheduling的定时器停止方式为cancel()pre-cpp20.mdvoid schedule_tick(std::string symbol, std::shared_ptrasio::steady_timer t) { t-expires_after(std::chrono::milliseconds(250)); auto self shared_from_this(); t-async_wait(asio::bind_executor(strand_, this, self, symbol, t { if (ec) return; // cancelled on unsubscribe/close → stops send(make_tick(symbol)); // enqueue on the write queue schedule_tick(symbol, t); // reschedule itself })); } // start: keep one timer per subscription alive (e.g. in a map); stop: erase t-cancel()实现要点定时器以shared_ptr持有并常驻例如存放在订阅 map 中防止定时器对象在等待期间析构每条链都bind_executor(strand_)确保与读/写链串行取消cancel()使在途async_wait以operation_aborted完成if (ec) return即优雅终止——这再次体现operation_aborted区分于真实错误的全局规则。构建差异回调 vs Stackful spawn回调风格除了 C 标准设置外无需额外依赖CMake 配置如下pre-cpp20.mdset(CMAKE_CXX_STANDARD 11) # or 14 / 17 set(CMAKE_CXX_EXTENSIONS OFF) # else CMake emits -stdgnuNN, not literal -stdcNN target_link_libraries(app PRIVATE Boost::headers Threads::Threads) target_compile_definitions(app PRIVATE BOOST_ERROR_CODE_HEADER_ONLY)而 stackfulspawn额外依赖 Boost.Coroutine其底层使用 Boost.Context不是 header-only必须显式链接find_package(Boost REQUIRED COMPONENTS coroutine) target_link_libraries(app PRIVATE Boost::coroutine) # pulls in Boost.Context综合 SKILL.md 的版本底线构建决策可以归纳为一张表场景结论C11–17 Boost ≥ 1.74回调风格即可仅需Boost::headersThreads::ThreadsBOOST_ERROR_CODE_HEADER_ONLYC11–17 想用spawn需链接Boost::coroutine三参数spawn(ex, fn, token)还需Boost ≥ 1.80standalone Asio 的spawn同样依赖 Boost.Coroutine/Context会把 Boost 拖进本无 Boost 的构建——想零 Boost 依赖就选回调风格旧发行版如 Debian bookwormBoost 1.74回调风格可干净编译stackfulspawn不行已实测验证两点补充说明BOOST_ERROR_CODE_HEADER_ONLY必须在恰好一处定义推荐在 CMake 的target_compile_definitions因为 Boost 1.74 起Boost::system组件已是 header-only无需链接Boost::system这是 SKILL.md 常见错误表中专门列出的误配置语言层面而非库层面的坑chrono 字面量250ms/30s是C14特性真正的 C11 构建应写作std::chrono::milliseconds(250)-fcoroutines只用于 C20 的co_awaitGCCPre-C20 风格不需要。三种风格如何选择决策建议结合 SKILL.md 的风格选择矩阵Step 1Pre-C20 场景下的推荐路径先确认工具链find_package(Boost)输出、dpkg -l libboost-dev、brew info boost、CMAKE_CXX_STANDARD或直接询问——不要假设最新版本Boost ≥ 1.77 且 C20用协程风格co_awaitawaitableT参考 coroutines.mdBoost ≥ 1.74 且 C11–17优先回调风格可移植基准参考本指南对应的 pre-cpp20.md确实需要同步式写法且 Boost ≥ 1.80可选用 stackfulspawnyield_context但接受链接 Boost.Coroutine 的代价Boost 1.62–1.65无io_context/make_strand/any_io_executor落入 classicio_service时代参考 classic-boost.md。无论选择哪种风格SSL/TLSssl::stream都是库特性各风格通用——注意 SSL 流的所有异步操作都要求 strand 同步见 ssl.md。提交前的自查清单参考 SKILL.md 的 Before you call it done 清单Pre-C20 代码应逐项核对风格匹配目标 Boost 版本与 C 标准且每个使用的 API 都满足其版本底线传给异步操作的每个缓冲区都存活到操作结束——回调风格禁止用局部变量改用成员变量杜绝悬垂string_view并发写时每 socket 至多一个在途async_write由队列 标志强制执行共享对象上的每条异步链运行在同一 strand每个 handler 都捕获self帧/定界读取使用组合读async_read/async_read_until而非async_read_some每个操作都检查错误回调的ec或yield[ec]不吞错重设定时器或取消操作产生的operation_aborted与真实错误区分处理CMake 包含标准设置、BOOST_ERROR_CODE_HEADER_ONLY仅一处、使用 stackfulspawn时链接Boost::coroutine实际编译验证——本仓库文档强调版本底线只有真正构建过才算数。赞分享AI 技能AI 插件人工智能【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills点击查看免费下载相关推荐终结工时黑洞Plane时间跟踪如何重塑团队效率认知终结工时黑洞Plane时间跟踪如何重塑团队效率认知 在技术团队的项目管理实践中最令人头疼的往往不是复杂的技术难题而是那些看似简单却永远理不清的工时糊涂账企业应用后端前端Simple Port Scanner基于 C20 与 Boost.Asio 的异步并发 TCP 端口扫描器实战指南Simple Port Scanner基于 C20 与 Boost.Asio 的异步并发 TCP 端口扫描器实战指南 本篇技术指南以 Cybersecurcurl异步回调事件驱动编程与回调函数的完整指南curl异步回调事件驱动编程与回调函数的完整指南 概述为什么需要异步编程 在现代网络应用中同步阻塞的I/O操作已成为性能瓶颈的主要来源。当你的应用程序需CLI网络上一篇TVBoxOSC解锁电视盒子的隐藏潜能打造你的智能家庭媒体中心 下一篇Font Awesome workflow for Alfred进阶教程自定义粘贴功能与偏好设置创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考