子版块

• ---

• Sunrisepeak's Blog

  Sunrisepeak的博客

  7 主题

  16 帖子

  S

  文章导读 一、类模板与模板特化(全特化与偏特化) 二、类模板与其模板特化的应用 三、模板特化存在性问题 一、类模板与模板特化(全特化与偏特化)

  从接受类型的角度
  类模板：全集R
  模板偏特化(部分特化)：为全集的一个子集A
  模板全特化：为R中的一个"点"，或者说为R中的一个元素
  匹配规则：越特化匹配优先级越高(见下面例子)

  98a9da6a-01af-4fc4-83ad-91b7ca549699-image.png

  1.类模板

  可以接受任意类型

  // R template<typename T> class A {}; // 类模板是能接受任意类型，A后面不需要(不能)任何处理 2.模板偏特化(局部特化)

  可以接受任意指针类型

  // A template<typename T> class A<T *> {}; // 类模板A的偏特化版本，在A后指出特化的范围 3.模板全特化

  指定接受int类型

  template<> class A<int> {} // 类模板A的全特化版本(已经是类模板的一个实例了)，在A后直接指出明确类型int 4.例子： #include <iostream> #include <string> using namespace std; template<typename T> class A { public: A() { cout << "R" << endl; } }; /* 注释1　－－　接受指针 template<typename T> class A<T *> { public: A() { cout << "A" << endl; } }; */ /* 注释2　－－　接受int template<> class A<int> { public: A() { cout << "int" << endl; } }; */ int main() { A<string> r; // 1 A<char *> a; // 2 A<int> i; // 3 return 0; } 5.测试不同情况:

  当只有一个类模板(可接受任意类型R)存在时，1, ２, 3都使用类模板实例化

  v2-a53836d6d2a913d69c2fd90b0dd4371f_1440w.png

  注释１是接受所以指针类型(R的子集A),所以称其为类模板A的偏特化(范围特化)。即把类模版A所能接受的指针类型单独处理(实例化)。当取消注释１时：char * 将由这个模板类A的偏特化版本(范围特化，局部特化)处理。

  v2-2bd02b7f6a4dbb5cdbc586f98d76b92b_1440w.png

  注释２只接受int类型的参数(可以看出是全局R中的一个元素)。当你用int实例化A时，将会由这个全特化版本来实现(而不会使用可以接受任意类型的版本(泛化版))。

  v2-6a08120bfe6da8471d8fb374b2665a65_1440w.png

  二、类模板与其模板特化的应用 用模板的偏特化　实现一个　能移除任意类型const属性的模板类：remove_const 主要功能和用法： 功能： 给remove_const一个类型后 －－１．(情况１)如果这个类型没有const属性则获得这个类型本身。 －－２．(情况２)如果这个类型有const属性则移除它。 用法： remove_const<Type>::type 使用场景： 当拿到一个未知变量时，想获得这个变量(或对象)的非const的类型 1.实现情况１

  似乎没做什么事，aa是int符合情况１。但情况２不符合，bb没有变成int。

  #include <iostream> #include <type_traits> template<typename T> struct remove_const { using type = T; }; int main() { int a = 1; const int b = 2; remove_const<decltype(a)>::type aa = 3; remove_const<decltype(b)>::type bb = 4; std::cout << std::is_same<decltype(aa), int>::value << std::endl; std::cout << std::is_same<decltype(bb), int>::value << std::endl; return 0; }

  运行结果:
  v2-7a36de2df8473699ecc173f27351c876_1440w.png

  2.实现情况2

  从上面的实现可以看出，当传给模板的参数是带const类型时它还会返回带const属性的类型。同时从remove_const的定义也可以看出他是个　复读机　你给他什么类型他就给你什么类型。

  这时候可以使用上面介绍的偏特化的性质，来把带有带const的类型这个子集从全集中分离出来　特殊处理。如下：

  #include <iostream> #include <type_traits> template<typename T> struct remove_const { using type = T; }; template<typename T> struct remove_const<const T> { using type = T; }; int main() { int a = 1; const int b = 2; remove_const<decltype(a)>::type aa = 3; remove_const<decltype(b)>::type bb = 4; std::cout << std::is_same<decltype(aa), int>::value << std::endl; std::cout << std::is_same<decltype(bb), int>::value << std::endl; return 0; }

  运行结果:

  给带const的类型，写了一个特化版本。所以当remove_const接受一个带const的类型时，就会通过这个偏特化版本实例化，由于这个偏特化版本把const从类型中分离出来了，则这里的T就是没有const的类型，从而实现去除类型const的功能。

  v2-d337e4dc338fc9a90fcfa7ef9db27804_1440w.png

  三、模板特化存在性问题

  一个类模板的特化，是对某一个类模板的子集做特化处理的。而它不能"独立存在"。既只有存在一个类模板X, 才能存在对它特化的版本。

  template<typename T> class A<T *> {}; int main() { return 0; }

  v2-1023f2d6ec20e5efa6300629068527d6_1440w.png

• invoker__qq's Blog

  invoker__qq的博客

  1 主题

  2 帖子

  S

  @tiansongyu 在 使用AI代理游玩所有任天堂NES游戏(红白机)详细教程----基于gym-retro、pygame、stable-baselines3 中说：

  示例图片 2

  这个中间的游戏 很经典的对站游戏。里面的 能发地波的忍者 和 哪个龙的 大鹏展翅 记忆深刻

• pinkie_ctfer's Blog

  pinkie ctfer的博客

  3 主题

  7 帖子

  妈

  本系列博客作为我学习的一个笔记,注重于代码实现,本人非数学专业,证明能力非常弱,本文掺杂着大量我自己的理解,如有数学大佬光顾,请尽情指正,谢谢
  本系列默认大家都学会了C/C++基本语法

  集合 书上的定义 集合是指具有某种特定性质的不同对象无序聚集成的一个整体。 集合中的每一个对象称为集合的元素； 通常用大写字母表示集合； 用小写字母表示集合中的元素。

  也就是说把一些东西放到一起叫做集合(个人理解)

  代码实现 #include <string> #include <vector> #include <stdint.h> #include <iostream> // 抽象基类，定义集合元素的基本接口 class elmBase { public: // 将元素转换为字节数组的纯虚函数（序列化基础） virtual std::vector<uint8_t> getUint8Array() const = 0; // 默认比较运算符，通过字节数组逐字节比较 virtual int operator==(const elmBase &other) { std::vector<uint8_t> thisDate = getUint8Array(); std::vector<uint8_t> otherDate = other.getUint8Array(); if (thisDate.size() != otherDate.size()) return 0; for (int i = 0; i < thisDate.size(); i++) { if (thisDate[i] != otherDate[i]) return 0; } return 1; } // 转换为字符串表示的纯虚函数 virtual std::string toString() = 0; // 虚析构函数确保正确释放派生类对象 virtual ~elmBase() { } }; // 特殊元素类型，始终返回比较不成立 class alwaysFalse : public elmBase { public: std::vector<uint8_t> getUint8Array() const override { return std::vector<uint8_t>(); // 返回空数组 } std::string toString() override { return {}; // 返回空字符串 } // 重载运算符始终返回false，用于占位符场景 virtual int operator==(const elmBase &other) override { return 0; } ~alwaysFalse() { } }; // 哈希表节点结构，使用链表法解决冲突 using elmNode = struct elmNode { elmBase *elm; // 元素指针 elmNode *next; // 下一个节点指针 }; // 节点工厂函数，创建新节点并初始化元素 elmNode *elmNodeFactory(elmBase *elm) { elmNode *newNode = new elmNode(); newNode->elm = elm; newNode->next = nullptr; return newNode; } // 自定义集合类，基于哈希表实现 class set { private: uint32_t prime; // 哈希表大小（通常选择质数） elmNode **setMap; // 哈希桶数组 // 初始化哈希表结构 void inline _init_(uint32_t prime) { this->prime = prime; this->setMap = new elmNode *[prime]; // 初始化每个桶为alwaysFalse哨兵节点 for (uint32_t i = 0; i < prime; ++i) { this->setMap[i] = elmNodeFactory(new alwaysFalse()); } } protected: // 查找元素对应的哈希桶 elmNode **__find__(elmBase *elm) { uint32_t hash = rotatingHash(elm->getUint8Array(), this->prime); return &(this->setMap[hash]); // 返回桶的指针 } /** * 通用链表操作函数 * @param link 链表头指针的指针 * @param elm 目标元素 * @param cmp 自定义比较函数，返回true时停止遍历 * @param finally 遍历结束后的处理函数（插入等操作） * @return 找到的节点或操作结果节点 */ elmNode *__link__(elmNode **link, elmBase *elm, bool (*cmp)(elmNode *, elmBase *), elmNode *(*finally)(elmNode **, elmNode *, elmBase *) = nullptr) { elmNode *linkPriv = *link; elmNode *linkCurrent = linkPriv; // 遍历链表查找元素 while (linkCurrent != nullptr) { if (cmp(linkCurrent, elm)) { return linkCurrent; } linkPriv = linkCurrent; linkCurrent = linkCurrent->next; } // 执行最终处理函数（如插入新节点） if (finally != nullptr) { return finally(link, linkPriv, elm); } return nullptr; } public: // 构造函数初始化哈希表 set(uint32_t prime) { _init_(prime); } ~set() { for (uint32_t i = 0; i < this->prime; ++i) { elmNode *link = this->setMap[i]; while (link != nullptr) { elmNode *tmp = link; link = link->next; if (tmp != nullptr) { if (tmp->elm != nullptr) { std::cout << "delete " << tmp->elm->toString() << std::endl; delete tmp->elm; } delete tmp; } } } } // 旋转哈希算法实现 static uint32_t rotatingHash(std::vector<uint8_t> key, uint32_t prime) { uint32_t hash = key.size(); for (uint32_t i = 0; i < key.size(); ++i) hash = (hash << 4) ^ (hash >> 28) ^ (uint32_t)(key[i]); return (hash % prime); } // 添加元素到集合 bool add(elmBase *elm, bool force = false) { elmNode **node = __find__(elm); auto finally = [](elmNode **node, elmNode *linkPriv, elmBase *elm) -> elmNode * { // 插入新节点到链表末尾 if (linkPriv->next == nullptr) { linkPriv->next = elmNodeFactory(elm); } return nullptr; }; // 使用lambda作为比较函数 elmNode *targetNode = this->__link__(node, elm, [](elmNode *node, elmBase *tag) -> bool { return *(node->elm) == *tag; }, finally); return targetNode == nullptr; // 返回是否插入成功 } // 检查元素是否存在 bool get(elmBase *elm) { elmNode **node = __find__(elm); elmNode *targetNode = this->__link__(node, elm, [](elmNode *node, elmBase *tag) -> bool { return *(node->elm) == *tag; }); return targetNode != nullptr; } // 移除集合中的元素 bool remove(elmBase *elm) { elmNode **node = __find__(elm); elmNode *ret = this->__link__(node, elm, [](elmNode *current, elmBase *tag) -> bool { // 查找前驱节点执行删除 if (current->next != nullptr && *(current->next->elm) == *tag) { elmNode *tmp = current->next; current->next = current->next->next; delete tmp->elm; // 释放元素内存 delete tmp; // 释放节点内存 return true; } return false; }); return ret != nullptr; } // 调试用打印函数，显示哈希表结构 void print() { std::cout << "[HashTable Structure]" << std::endl; for (int i = 0; i < this->prime; i++) { std::cout << "Bucket " << i << ": "; elmNode *node = this->setMap[i]; while (node != nullptr) { std::cout << node->elm->toString() << " -> "; node = node->next; } std::cout << "NULL" << std::endl; } } }; // 数值类型元素实现 class number : public elmBase { int data; public: number(int data) : data(data) {} std::vector<uint8_t> getUint8Array() const override { // 将整型转换为字节数组 return std::vector<uint8_t>( reinterpret_cast<const uint8_t *>(&data), reinterpret_cast<const uint8_t *>(&data) + sizeof(data)); } std::string toString() override { return std::to_string(data); } ~number() { } }; // 字符串类型元素实现 class string : public elmBase { std::string data; public: string(std::string data) : data(data) {} std::vector<uint8_t> getUint8Array() const override { // 将字符串内容转换为字节数组 return std::vector<uint8_t>(data.begin(), data.end()); } std::string toString() override { return data; } ~string() { } }; 集合与元素的关系 若A表示一个集合，a是集合A中的元素，记作aA，读作a属于A； 若a不是集合A中的元素，则记作aA，读作a不属于A。

  未完待续

• Maxwell1905's Blog

  Maxwell1905的博客

  4 主题

  20 帖子

  S

  @sky-littlestar 我说的意思就是把你上面的代码 整理一下 用项目(Demo)的方式 放到github, 不是说其他什么写法

• FrozenLemonTee's Blog

  冰柠配绿茶的个人博客, 记录探索技术的历程 - Github | X

  2 主题

  8 帖子

  F

  @SPeak 具体没研究过，不过JetBrains的IDE集成程度比vscode高，可能不太能通过命令或者修改配置文件的方式来修改。如果有朋友有相关了解的可以贴在这里。

• Blog :: Johan Xie

  个人博客，随想随写

  0 主题

  0 帖子

  没有新主题
• xin

  个人博客，随想随写 - Doomjustin

  18 主题

  23 帖子

  D

  这是在学习了capy的隐式注入玩法后的更新。他的方案帮我梳理了我原本混乱的思路，感觉自己的目光都清撤了许多。

  旧版本的困局：stop_then 手动包装

  旧版本就是让用户手工拼装，每个 awaitable 都得用 stop_then 包一下：

  co_await stop_then(some_io_operation(), stop_token); // 得手动拼，十分繁琐

  这种操作确实实现了取消，但是所有的复杂性都暴露给了业务代码：

  编写 co_await 时需要考虑"这个操作是否需要取消？" 如果需要，必须记得手动包裹 stop_then。 遗漏任何一个，就会产生"无法取消的操作"，取消时挂起。

  值得一提的是，原本的实现由于混乱的思路引入了各种多线程问题。但是在梳理之后发现都是不必要处理的操作，属于是自己把自己坑进去了。

  新版本的改进：隐式注入取消 消除业务层污染

  旧方案的致命缺陷不在技术复杂度，而在于污染。业务代码里到处是 stop_then，每个 I/O 函数签名都要添加 std::stop_token 参数，这直接增加了维护成本和开发者的认知负担。

  // 旧方案：取消把整个调用链都污染了 Task<> handle_client(IOContext& ctx, std::stop_token token) { auto res = co_await stop_then(async_read(fd, buffer), token); // 得手动拼 if (!res && res.error() == std::errc::operation_canceled) { // 处理被取消 } }

  我原本认为用户可能需要自己选择可取消和不可取消，所以通过stop_then包装器可以提供最大的自由度。但是实际上，我想不出什么操作是不需要被取消的，甚至更进一步的想，一旦出现了不可取消的挂起操作，某种意义上其实可以算作一种资源泄露bug了。

  想法来源：从 capy 的实现中得到启发，我发现可以用 C++20 的 await_transform 重新设计这一层。capy 为了通用性，通过 env 注入 executor、allocator、stop_token 等参数；而我们的框架强绑定 io_uring，所以能更直接地在 promise 层注入 IOContext 和 stop_token，并统一依赖 ASYNC_CANCEL 语义。正因为这些都能确定下来，所以取消机制才能被完全自动化。

  核心改进：三层隐式注入

  第一层：Promise 环境绑定

  每个 Task 的 promise 自动持有当前的 IOContext 和 stop_token，无需用户处理：

  struct StoppablePromise { IOContext& context_; std::stop_token stop_token_; // ... };

  第二层：await_transform 统一拦截

  利用 C++20 的 await_transform 机制，框架可以在业务代码的每一个 co_await IOAwaiter 处进行拦截，自动将其升级为"取消感知"版本：

  // 新模型：零污染，框架自动处理 Task<> handle_client() { auto res = co_await async_read(fd, buffer); // 框架自动注入取消机制 if (!res && res.error() == std::errc::operation_canceled) { // 处理取消情况 } }

  第三层：统一落地语义

  StopTokenWrapper 在 awaiter 挂起期间隐式注册取消回调。被取消操作的最终结果由原操作的 completion 决定：

  也是在重新设计这块时，我发现并不需要处理 ASYNC_CANCEL 的 cqe，直接丢掉，反而让整个实现简单起来了，没有复杂的生命周期问题，也没有了被取消操作和取消操作的时序问题，被 resume 时一定是被取消操作的结果返回了，而且被取消操作的结果也是精确地，result会被正确设置。

  template<typename Promise> auto await_suspend(std::coroutine_handle<Promise> handle) noexcept -> std::coroutine_handle<> { auto inner_handle = inner_.await_suspend(handle, context()); // 核心：在挂起期隐式注册取消回调 if (promise_->stop_token.stop_possible()) stop_callback_.emplace(promise_->stop_token, CancelFn{ this }); return inner_handle; } // 取消触发时的统一路径 void CancelFn::operator()() noexcept { if constexpr (cancellable<Awaitable>) wrapper->inner_.cancel(wrapper->context()); // 若 Awaiter 实现 cancel，直接调用 else wrapper->context().cancel(wrapper->inner_); // 否则走 ASYNC_CANCEL } 修改后

  隐式注入：用户编写普通的 co_await，框架在后台自动升级为"取消感知"版本。

  生命周期简化：由于 cancel CQE 直接扔掉，不再跟踪，stop_callback 的生命周期严格绑定在 awaiter 挂起这段期间。不需要 shared_ptr<bool> 守卫了。

  awaiter 契约统一：

  要是 awaiter 实现了 cancel(io_context) 方法，框架就调它。 否则用默认的 io_uring ASYNC_CANCEL 方式。 核心代码对比

  旧版本（用户手动拼）：

  auto task = [](std::stop_token token) -> async::Task<> { co_await stop_then(some_io(), token); // 得手动传 token，手动调用 stop_then }; co_await async::any(task(group.stop_token()), ...);

  新版本（框架自动处理）：

  auto task = []() -> async::Task<> { co_await some_io(); // 啥都不用干，框架已经全搞定 }; // stop_token 框架内部在 Task::promise 里已经绑了，用户看不见 多线程下的行为对比 旧版本 主线程 (IOContext.run()) ↓ [处理 I/O 完成事件A] ↓ task 协程被唤醒 ↓ stop_then 析构（alive_ = false） ↓ 后台定时器线程 ↓ [发送 stop_token cancel] ↓ post 任务进入队列 ↓ [IOContext 取出 post 任务，检查 alive_] ↓ *alive_ == false，安全丢弃

  陷阱：如果 post 任务执行前，协程没析构，就访问了已 free 的内存。

  新版本 主线程 (IOContext.run()) ↓ task 协程开始 co_await some_io() ↓ await_transform 自动把它包装成 StopTokenWrapper ↓ stop_callback 被注册在 wrapper 的栈帧上 ↓ 后台定时器线程 ↓ [stop_token 被触发] ↓ stop_callback 立刻在这个线程上执行（标准库保证线程安全） ↓ 调用 awaiter.cancel(context) 把 cancel 指令 post 回主线程 ↓ 主线程 (IOContext.run()) ↓ [从事件循环取出 cancel 指令] ↓ 发送 ASYNC_CANCEL SQE 给内核 ↓ 原操作的 CQE 返回 -ECANCELED 或原结果 ↓ awaiter 恢复协程，返回错误给上层

  如此一来：

  stop_callback 本身线程安全（标准库保证）。 cancel 动作在 IOContext 里执行，安全、可控。 栈帧生命周期自动保护，不需要 shared_ptr 守卫。 结尾

  由于这个修改算是撬了最底层的设计，所以导致绝大部分的模块都需要重写。不过在理清了混乱之后，所有的实现相较于旧版本都变得简单了很多，甚至绝大部分的Awaiter实现都变成了下面这种极简版本，也就是继承一下IOAwaiter，写个 prepare()和构造函数就完事了。

  class SendAwaiter : public async::IOAwaiter<SendAwaiter, std::size_t> { private: int fd_; std::span<const std::byte> buffer_; public: SendAwaiter(int fd, std::span<const std::byte> buffer) : fd_{ fd } , buffer_{ buffer } {} void prepare(::io_uring_sqe* sqe) const noexcept { ::io_uring_prep_send(sqe, fd_, buffer_.data(), buffer_.size(), MSG_NOSIGNAL); } };