1. 项目概述为什么要在C中再造Qt的信号与槽如果你用过Qt肯定对它的信号与槽机制印象深刻。它让对象间的通信变得优雅而解耦一个connect就能把两个毫不相干的对象关联起来发射信号槽函数自动响应。但有时候我们手头的项目可能无法引入庞大的Qt框架或者我们想深入理解这种机制的底层原理甚至想在一个纯C项目中复现这种松耦合的通信体验。这就是我们今天要聊的话题用标准C从零开始实现一套类似Qt的信号与槽系统。这不仅仅是一个“造轮子”的练习。通过亲手实现你会对C的模板元编程、函数对象、类型擦除、内存管理等高级特性有更深刻的理解。你会明白Qt是如何在幕后管理连接的生命周期如何处理线程安全以及如何实现那令人舒适的语法糖。对于面试官常问的“观察者模式如何实现”、“C如何实现回调”这类问题你也能给出一个远超普通答案的、有深度的实现方案。接下来我将带你从设计思路开始一步步拆解、实现并优化最终得到一个可用的、轻量级的信号槽库。2. 核心设计思路与架构拆解在动手写代码之前我们必须想清楚几个核心问题信号是什么槽是什么连接Connect的本质是什么如何保证类型安全如何管理连接的生命周期2.1 信号的本质一个可调用对象的集合在Qt中信号看起来像一个特殊的成员函数但发射信号emit实际上是在调用这个函数进而通知所有连接到这个信号的槽。在我们的C实现中我们可以将“信号”抽象为一个对象其内部维护了一个列表这个列表里存放着所有与之连接的“槽”。这个“槽”可以是任何可调用对象全局函数、静态函数、成员函数、Lambda表达式甚至是另一个“信号”对象对应Qt的Qt::DirectConnection或队列连接的概念。因此我们的Signal类模板的核心数据结构可能是一个std::vector或std::list里面存放着某种统一的“可调用对象包装器”。当信号被“发射”即调用其operator()时它会遍历这个列表依次调用每一个包装器。2.2 槽的抽象类型擦除与统一包装槽的类型千变万化如何将它们存进同一个容器这就需要“类型擦除”技术。C中常见的类型擦除手段有使用基类指针如std::function的内部机制、使用模板和继承。我们将采用类似std::function的思路定义一个抽象的Callable基类然后通过模板派生类来保存具体的可调用对象及其参数。// 抽象的调用接口 class AbstractCallable { public: virtual ~AbstractCallable() default; virtual void call(const void* args) 0; // 通过void*传递参数包需要小心处理 };但直接使用void*和const void*来传递参数既危险又笨拙。更优雅的方式是利用C11的可变参数模板让Signal类模板本身接受参数类型并在内部定义一个知道具体参数类型的Callable模板。2.3 连接的管理连接句柄与自动断开Qt中QObject::connect返回一个QMetaObject::Connection对象可用于手动断开连接。更重要的是当发送者或接收者如果是成员函数槽被销毁时连接会自动断开这是防止悬空回调的关键。在我们的实现中也需要提供类似的机制。连接句柄connect方法可以返回一个Connection对象它内部可能保存了信号中对应槽的迭代器或唯一ID通过这个句柄可以手动disconnect。自动断开针对对象生命周期这是难点。对于连接到成员函数的槽我们需要知道“接收者对象”的地址。一种经典做法是让接收者对象继承自一个公共的基类例如Trackable该基类拥有一个唯一标识符或弱引用。当信号需要调用成员函数槽时它先检查接收者对象是否还“存活”。这通常通过std::weak_ptr或自定义的“存活标记”来实现。另一种更轻量但侵入性更强的做法是要求槽函数使用std::shared_ptr或std::weak_ptr来捕获对象。2.4 线程安全考量Qt的信号槽支持跨线程连接Qt::QueuedConnection这涉及事件循环和线程间通信。我们初版实现可以聚焦于线程不安全的“直接连接”即信号发射时在当前线程同步调用所有槽函数。这对于单线程应用或明确线程边界的场景已经足够。如果后续需要支持线程安全可以在连接时指定策略并在信号内部使用互斥锁如std::mutex保护槽列表。注意直接在信号发射函数里加锁要非常小心死锁。如果一个槽函数内部又发射了信号甚至可能是同一个信号就会导致重入锁死。Qt通过事件队列Queued Connection巧妙地避免了这个问题我们在简单实现中可以先规避这种复杂场景或规定不允许在槽中发射同一个信号。基于以上分析我们的实现将分为几个步骤首先实现一个基础版本支持函数对象和Lambda然后扩展支持成员函数和自动断开最后考虑线程安全和性能优化。3. 基础版本实现支持函数对象与Lambda我们先从最简单的场景开始信号可以连接任意可调用对象函数指针、std::function、Lambda发射信号时同步调用它们。暂不考虑成员函数和对象生命周期。3.1 定义Signal类模板我们的Signal类需要是一个模板模板参数是它所代表的函数的签名返回类型和参数类型。例如Signalvoid(int, std::string)对应一个接受int和string参数、无返回值的信号。#include vector #include functional #include memory #include algorithm templatetypename... Args class Signal { public: using SlotType std::functionvoid(Args...); // 连接一个槽函数返回一个连接ID可用于断开 int connect(SlotType slot) { slots_.push_back(slot); return static_castint(slots_.size()) - 1; // 简单返回索引作为ID } // 通过连接ID断开 void disconnect(int id) { if (id 0 id static_castint(slots_.size())) { // 这里不能直接erase因为会改变后续元素的索引。 // 我们可以将其置为一个空函数或者使用一个更复杂的结构来标记“无效”。 slots_[id] nullptr; // 置空实际调用时跳过 } } // 发射信号 void emit(Args... args) { for (auto slot : slots_) { if (slot) { // 跳过被断开置空的槽 slot(args...); } } // 可选清理被置空的槽避免列表膨胀 slots_.erase( std::remove_if(slots_.begin(), slots_.end(), [](const SlotType s) { return !s; }), slots_.end()); } // 重载()操作符提供类似函数调用的语法 void operator()(Args... args) { emit(args...); } private: std::vectorSlotType slots_; };这个版本非常简洁。它使用std::functionvoid(Args...)作为统一的槽类型存储在std::vector中。connect返回一个整数IDdisconnect根据ID将对应的std::function置空emit遍历并调用所有非空的槽。使用示例#include iostream void freeFunction(int x) { std::cout Free function: x std::endl; } int main() { Signalint sig; // 连接自由函数 int conn1 sig.connect(freeFunction); // 连接Lambda表达式 int conn2 sig.connect([](int x) { std::cout Lambda: x * 2 std::endl; }); // 发射信号 sig.emit(42); // 输出两行 // 断开一个连接 sig.disconnect(conn1); sig.emit(100); // 只输出Lambda那一行 return 0; }3.2 基础版本的局限性这个“玩具”版本虽然能用但问题很多连接管理脆弱使用整数ID一旦我们清理了slots_向量比如在emit中移除空槽之前返回的ID就全部失效了指向错误的元素。这是一个严重的缺陷。不支持成员函数无法直接连接MyClass::memberFunc。没有自动断开如果槽函数捕获了一个对象的指针比如Lambda里用了[this]而这个对象后来被销毁了再次发射信号就会导致未定义行为悬空指针调用。性能每次emit都需要检查slot是否为空并且std::function的调用有一定开销。接下来我们要着手解决最紧迫的前两个问题。4. 进阶实现健壮的连接管理与成员函数支持4.1 改进连接句柄我们需要一个不受容器内部操作影响的连接句柄。一个常见的做法是使用std::shared_ptr或std::weak_ptr来管理每个槽的“存在性”。这里我们定义一个新的Connection类它内部持有一个std::weak_ptr指向信号内部为每个槽分配的控制块。class Connection { public: Connection() default; explicit Connection(const std::shared_ptrvoid tracker) : tracker_(tracker) {} // 判断连接是否还有效槽是否还存在 bool connected() const { return !tracker_.expired(); } // 手动断开连接 void disconnect() { tracker_.reset(); } private: std::weak_ptrvoid tracker_; // 类型擦除的弱引用 };在Signal内部我们不再直接存储std::function而是存储一个包含std::function和std::shared_ptrvoid的结构体。这个shared_ptr就是控制块当它被销毁引用计数为0时意味着这个连接在逻辑上“断开”了。connect方法会创建这个控制块并返回一个包装了其weak_ptr的Connection对象。4.2 支持成员函数连接为了连接成员函数我们需要在connect时绑定一个对象实例。我们可以提供一个重载的connect函数接受对象指针和成员函数指针。这里的关键是如何将obj-method(args...)的调用包装成一个std::functionvoid(Args...)。我们可以使用std::bind或者Lambda来捕获对象指针。templatetypename... Args class Signal { public: using SlotType std::functionvoid(Args...); // 连接普通函数对象Lambda, std::function等 Connection connect(SlotType slot) { auto tracker std::make_sharedint(0); // 控制块内容不重要重要的是shared_ptr本身 SlotHolder holder{std::move(slot), tracker}; slots_.push_back(std::move(holder)); return Connection(tracker); } // 连接成员函数 templatetypename T, typename Method Connection connect(T* obj, Method method) { // 使用Lambda捕获对象指针和成员函数指针 return connect([obj, method](Args... args) { (obj-*method)(args...); }); } void emit(Args... args) { // 遍历前先清理已失效的连接 cleanup(); for (auto holder : slots_) { if (holder.tracker.use_count() 0) { // 或者检查function是否可调用 holder.func(args...); } } } private: struct SlotHolder { SlotType func; std::shared_ptrvoid tracker; // 用于判断连接是否存活 }; std::vectorSlotHolder slots_; void cleanup() { slots_.erase(std::remove_if(slots_.begin(), slots_.end(), [](const SlotHolder h) { return h.tracker.use_count() 1; // 只有容器本身持有引用 }), slots_.end()); } };现在我们的Connection对象是可靠的。即使信号内部清理了失效的槽Connection对象通过检查tracker_.expired()也能正确报告连接状态。成员函数连接也得以支持。使用示例class Receiver { public: void onEvent(int value) { std::cout Receiver got: value std::endl; } }; int main() { Signalint signal; Receiver recv; // 连接成员函数 Connection conn signal.connect(recv, Receiver::onEvent); signal.emit(100); // 输出: Receiver got: 100 // 手动断开 conn.disconnect(); signal.emit(200); // 无输出 // 自动断开场景需要更复杂的生命周期管理见下文 { Receiver recv2; Connection conn2 signal.connect(recv2, Receiver::onEvent); signal.emit(300); // 输出: Receiver got: 300 } // recv2 离开作用域被销毁 signal.emit(400); // 理想情况应无输出但当前实现可能导致悬空调用 }如示例最后所示当recv2对象被销毁后我们仍然持有指向它的Lambda通过[obj, method]捕获。此时再发射信号就会调用一个已经销毁对象的成员函数这是灾难性的。我们基础的成员函数连接并没有解决自动断开的问题。5. 核心挑战对象生命期管理与自动断开这是实现一个健壮信号槽系统最复杂的部分。Qt依靠其元对象系统知道每个QObject的生死。我们的纯C实现没有这样的基础设施需要自己设计一套机制。5.1 基于std::weak_ptr的自动断开最符合现代C习惯的做法是要求接收对象必须由std::shared_ptr管理。我们的connect函数可以接受一个std::weak_ptrT和一个成员函数。在调用槽之前先尝试将weak_ptr提升为shared_ptr如果提升失败对象已销毁则跳过或移除该连接。templatetypename... Args class Signal { public: // ... 其他成员 ... // 连接由shared_ptr管理对象的成员函数 templatetypename T, typename Method Connection connect(std::weak_ptrT weak_obj, Method method) { // 这里我们创建一个SlotType它内部会检查对象是否存活 auto slot [weak_obj, method](Args... args) { std::shared_ptrT obj weak_obj.lock(); if (obj) { (obj-*method)(args...); } // 如果提升失败这个lambda什么也不做。 // 更好的做法是通知Signal这个连接已失效但这需要更复杂的交互。 }; // 我们需要一种方式当weak_obj失效时能自动清理这个slot。 // 一个技巧是将weak_obj的“失效回调”与连接关联。但这需要侵入weak_ptr或自定义智能指针。 // 更实用的方法是在每次emit时检查并清理所有失效的连接性能有损耗。 return connect(std::move(slot)); } };这种方法将生命周期管理的责任交给了std::shared_ptr/std::weak_ptr对使用者有侵入性必须用智能指针管理对象但实现相对清晰。在emit函数中我们仍然需要cleanup来移除那些因为对象销毁而永远无法再成功的槽。5.2 侵入式跟踪Trackable基类另一种经典模式是提供一个Trackable基类所有希望自动断开连接的对象都继承它。Trackable内部有一个唯一标识符如std::atomicint64_t生成的ID和一个标志如std::atomicbool或std::shared_ptrbool。当对象析构时将标志置为false。连接时不仅传递对象指针和成员函数还传递这个“存活标志”的weak_ptr。在槽函数调用前先检查标志。class Trackable { public: using AliveFlag std::shared_ptrbool; Trackable() : alive_(std::make_sharedbool(true)) {} virtual ~Trackable() { *alive_ false; } // 析构时标记为死亡 AliveFlag getAliveFlag() const { return alive_; } private: AliveFlag alive_; }; templatetypename... Args class Signal { public: templatetypename T, typename Method Connection connect(T* obj, Method method) { // 静态断言确保T继承自Trackable static_assert(std::is_base_ofTrackable, T::value, Class must inherit from Trackable for automatic disconnection); auto alive_flag static_castTrackable*(obj)-getAliveFlag(); auto slot [alive_flag, obj, method](Args... args) { if (*alive_flag) { // 检查对象是否还存活 (obj-*method)(args...); } }; // 我们需要在alive_flag所指的bool变为false时自动断开连接。 // 这可以通过将alive_flag与连接关联并在cleanup时检查来实现。 // 但更直接的是在SlotHolder里也保存这个alive_flag的weak_ptr并在调用前检查。 std::weak_ptrbool weak_flag(alive_flag); auto tracker std::make_sharedint(0); SlotHolder holder{std::move(slot), tracker, weak_flag}; // 新增weak_flag成员 slots_.push_back(std::move(holder)); return Connection(tracker); } private: struct SlotHolder { SlotType func; std::shared_ptrvoid tracker; std::weak_ptrbool objAliveFlag; // 对象存活标志的弱引用 }; void cleanup() { slots_.erase(std::remove_if(slots_.begin(), slots_.end(), [](const SlotHolder h) { // 连接失效的条件1. tracker唯一 或 2. 对象已死亡 bool trackerDead h.tracker.use_count() 1; bool objDead false; if (auto sp h.objAliveFlag.lock()) { objDead !(*sp); // 如果拿到了指针但标志为false } else { objDead true; // 连指针都拿不到了对象肯定死了 } return trackerDead || objDead; }), slots_.end()); } };这种方法要求对象继承自特定基类也有一定的侵入性但避免了强制使用shared_ptr。cleanup逻辑现在会同时检查连接句柄是否被放弃以及目标对象是否存活。实操心得在实际项目中侵入式Trackable和非侵入式shared_ptr两种方案各有优劣。如果项目代码结构允许继承Trackable可能更轻量。如果项目已广泛使用shared_ptr那么基于weak_ptr的方案更自然。你也可以同时提供两种connect重载让使用者选择。切记不要混合使用两种方式管理同一个对象的连接会导致混乱。6. 性能优化与线程安全扩展6.1 性能优化点内存分配每次connect都涉及std::function的构造和std::shared_ptr的控制块分配。对于高频连接的场景可以考虑使用内存池或小对象优化。遍历开销emit时需要遍历所有槽并检查有效性。如果槽数量很多cleanup和条件检查会成为瓶颈。可以考虑将“失效标记”与调用分离或者使用双缓冲区策略在emit时使用一个快照列表避免在遍历时修改原列表。std::function的开销std::function的调用有间接层。如果对性能有极致要求可以尝试使用模板化的槽存储利用C的编译期多态。但这会显著增加代码复杂度和编译时间。一个简单的优化是在Signal内部使用std::liststd::pairConnection, SlotType或类似结构来存储槽这样在断开连接时通过Connection对象可以以O(1)复杂度从列表中移除元素而无需在cleanup时遍历整个列表。Connection内部可以保存一个指向链表节点的迭代器。6.2 线程安全初步实现为了支持多线程环境下的连接和发射我们需要保护内部的slots_容器。一个粗粒度的做法是在connect、disconnect和emit函数中都加锁。#include mutex templatetypename... Args class Signal { public: Connection connect(SlotType slot) { std::lock_guardstd::mutex lock(mutex_); // ... 原有的连接逻辑 ... } void emit(Args... args) { // 关键在锁的保护下复制一份当前有效的槽函数列表。 std::vectorSlotHolder slotsCopy; { std::lock_guardstd::mutex lock(mutex_); cleanup(); // 清理需要在锁内进行 slotsCopy slots_; // 复制 } // 在锁外调用槽函数避免死锁。 for (auto holder : slotsCopy) { if (holder.tracker.use_count() 1) { // 检查复制品中的tracker holder.func(args...); } } } private: mutable std::mutex mutex_; // ... 其他成员 ... };重要警告上述线程安全实现是基础的但存在一个经典竞态条件在connect函数中我们创建SlotHolder并加入到slots_然后创建Connection。如果Connection的创建和返回在锁之外另一个线程可能在拿到Connection之前就发射信号导致它试图连接一个尚未完全加入列表的槽实际上由于Connection的创建依赖于slots_中的tracker这个操作必须在锁内完成。所以connect应该返回在锁内构造好的Connection。此外槽函数的执行线程是另一个大问题。上面的emit在调用槽时槽是在发射信号的线程中执行的。如果槽函数内部有耗时操作或访问了其他线程的数据可能会引发问题。Qt的QueuedConnection就是将调用请求打包成事件投递到接收对象所在线程的事件队列中。实现这个功能需要完整的消息队列和线程事件循环这超出了轻量级信号槽的范围。因此我们的线程安全版本应明确标注为“直接连接槽在发射线程同步执行”并提醒使用者注意槽函数的线程安全性。7. 常见问题与排查技巧实录在实现和使用自制的信号槽系统时你可能会遇到以下典型问题7.1 连接未生效或重复调用症状信号发射后槽函数没有被调用或者被调用了多次。排查检查连接返回值确认connect调用成功并保存了返回的Connection对象。如果Connection对象被立即销毁例如临时对象可能会导致连接刚建立就被断开如果Connection析构函数调用disconnect的话我们目前的实现没有这样做但某些库会。检查对象生命周期如果连接的是成员函数确保接收者对象在信号发射时仍然存活。使用我们基于Trackable或weak_ptr的方案可以在cleanup逻辑中加入调试输出查看连接是否因对象死亡被清理。重复连接我们的简单实现允许同一个槽被连接多次。如果你不小心连接了两次它就会被调用两次。如果需要唯一连接可以在connect内部检查是否已经存在相同的槽比较std::function对象比较棘手但可以比较对象地址和成员函数指针或要求使用者保证。7.2 程序崩溃悬空指针症状在信号发射时程序发生段错误或访问违例。排查这是最常见的原因接收者对象已被销毁但连接未断开。务必使用我们实现了自动断开机制的版本Trackable或weak_ptr。如果使用原始指针连接你必须手动管理生命周期在对象析构前断开所有连接。在槽函数中访问了无效数据即使对象本身存活槽函数内部访问的其他数据可能已失效。确保槽函数本身的逻辑是线程安全和生命周期安全的。信号对象本身被销毁后仍在发射确保发射信号的代码不会在信号对象析构后被调用。通常信号对象作为类的成员变量其生命周期应与所属对象一致。7.3 性能瓶颈症状程序运行变慢尤其是频繁发射信号的场景。排查与优化Profile使用性能分析工具如gprof, perf, VTune确定热点是否在信号槽的emit或cleanup中。减少槽函数数量审视设计是否每个连接都是必要的能否合并一些处理逻辑优化cleanup策略不要在每次emit时都清理。可以设置一个计数器每发射N次信号清理一次或者只在连接/断开时标记“脏位”在下次emit时清理。考虑无锁设计对于超高并发场景可以研究无锁队列来存储槽函数但这会极大增加实现复杂度。绝大多数情况下使用互斥锁并优化临界区范围已经足够。7.4 线程相关错误症状数据竞争、死锁或槽函数在错误线程中执行导致UI更新失败在GUI程序中常见。排查与解决明确线程模型你的信号槽是用于单线程、多线程发射单线程接收还是多对多我们的基础线程安全版本只保证了容器操作的线程安全不保证槽函数的执行线程。GUI编程如果你在类似Qt的GUI环境中使用自制信号槽更新界面必须确保更新UI的槽函数在UI线程主线程中被调用。这需要你将信号发射与UI线程调度耦合。在我们的系统中这通常意味着槽函数内部需要将实际工作post到UI线程的事件循环中而不是直接执行。避免死锁确保槽函数内部不要试图去锁定一个可能被信号发射线程锁住的资源。如果槽函数复杂尽量保持其不持有任何锁。实现一个完整的、生产级的信号槽库需要考虑的边界情况非常多比如信号槽的递归调用、阻塞连接、连接类型直接、队列、唯一连接等。但通过以上步骤我们已经构建了一个在单线程或明确线程边界下非常实用的、具备自动断开能力的C信号槽系统核心。理解了这个核心你就能根据具体项目需求进行裁剪、扩展和优化。
C++实现信号槽机制：从原理到实践，打造轻量级对象通信框架
发布时间：2026/7/26 5:06:34
1. 项目概述为什么要在C中再造Qt的信号与槽如果你用过Qt肯定对它的信号与槽机制印象深刻。它让对象间的通信变得优雅而解耦一个connect就能把两个毫不相干的对象关联起来发射信号槽函数自动响应。但有时候我们手头的项目可能无法引入庞大的Qt框架或者我们想深入理解这种机制的底层原理甚至想在一个纯C项目中复现这种松耦合的通信体验。这就是我们今天要聊的话题用标准C从零开始实现一套类似Qt的信号与槽系统。这不仅仅是一个“造轮子”的练习。通过亲手实现你会对C的模板元编程、函数对象、类型擦除、内存管理等高级特性有更深刻的理解。你会明白Qt是如何在幕后管理连接的生命周期如何处理线程安全以及如何实现那令人舒适的语法糖。对于面试官常问的“观察者模式如何实现”、“C如何实现回调”这类问题你也能给出一个远超普通答案的、有深度的实现方案。接下来我将带你从设计思路开始一步步拆解、实现并优化最终得到一个可用的、轻量级的信号槽库。2. 核心设计思路与架构拆解在动手写代码之前我们必须想清楚几个核心问题信号是什么槽是什么连接Connect的本质是什么如何保证类型安全如何管理连接的生命周期2.1 信号的本质一个可调用对象的集合在Qt中信号看起来像一个特殊的成员函数但发射信号emit实际上是在调用这个函数进而通知所有连接到这个信号的槽。在我们的C实现中我们可以将“信号”抽象为一个对象其内部维护了一个列表这个列表里存放着所有与之连接的“槽”。这个“槽”可以是任何可调用对象全局函数、静态函数、成员函数、Lambda表达式甚至是另一个“信号”对象对应Qt的Qt::DirectConnection或队列连接的概念。因此我们的Signal类模板的核心数据结构可能是一个std::vector或std::list里面存放着某种统一的“可调用对象包装器”。当信号被“发射”即调用其operator()时它会遍历这个列表依次调用每一个包装器。2.2 槽的抽象类型擦除与统一包装槽的类型千变万化如何将它们存进同一个容器这就需要“类型擦除”技术。C中常见的类型擦除手段有使用基类指针如std::function的内部机制、使用模板和继承。我们将采用类似std::function的思路定义一个抽象的Callable基类然后通过模板派生类来保存具体的可调用对象及其参数。// 抽象的调用接口 class AbstractCallable { public: virtual ~AbstractCallable() default; virtual void call(const void* args) 0; // 通过void*传递参数包需要小心处理 };但直接使用void*和const void*来传递参数既危险又笨拙。更优雅的方式是利用C11的可变参数模板让Signal类模板本身接受参数类型并在内部定义一个知道具体参数类型的Callable模板。2.3 连接的管理连接句柄与自动断开Qt中QObject::connect返回一个QMetaObject::Connection对象可用于手动断开连接。更重要的是当发送者或接收者如果是成员函数槽被销毁时连接会自动断开这是防止悬空回调的关键。在我们的实现中也需要提供类似的机制。连接句柄connect方法可以返回一个Connection对象它内部可能保存了信号中对应槽的迭代器或唯一ID通过这个句柄可以手动disconnect。自动断开针对对象生命周期这是难点。对于连接到成员函数的槽我们需要知道“接收者对象”的地址。一种经典做法是让接收者对象继承自一个公共的基类例如Trackable该基类拥有一个唯一标识符或弱引用。当信号需要调用成员函数槽时它先检查接收者对象是否还“存活”。这通常通过std::weak_ptr或自定义的“存活标记”来实现。另一种更轻量但侵入性更强的做法是要求槽函数使用std::shared_ptr或std::weak_ptr来捕获对象。2.4 线程安全考量Qt的信号槽支持跨线程连接Qt::QueuedConnection这涉及事件循环和线程间通信。我们初版实现可以聚焦于线程不安全的“直接连接”即信号发射时在当前线程同步调用所有槽函数。这对于单线程应用或明确线程边界的场景已经足够。如果后续需要支持线程安全可以在连接时指定策略并在信号内部使用互斥锁如std::mutex保护槽列表。注意直接在信号发射函数里加锁要非常小心死锁。如果一个槽函数内部又发射了信号甚至可能是同一个信号就会导致重入锁死。Qt通过事件队列Queued Connection巧妙地避免了这个问题我们在简单实现中可以先规避这种复杂场景或规定不允许在槽中发射同一个信号。基于以上分析我们的实现将分为几个步骤首先实现一个基础版本支持函数对象和Lambda然后扩展支持成员函数和自动断开最后考虑线程安全和性能优化。3. 基础版本实现支持函数对象与Lambda我们先从最简单的场景开始信号可以连接任意可调用对象函数指针、std::function、Lambda发射信号时同步调用它们。暂不考虑成员函数和对象生命周期。3.1 定义Signal类模板我们的Signal类需要是一个模板模板参数是它所代表的函数的签名返回类型和参数类型。例如Signalvoid(int, std::string)对应一个接受int和string参数、无返回值的信号。#include vector #include functional #include memory #include algorithm templatetypename... Args class Signal { public: using SlotType std::functionvoid(Args...); // 连接一个槽函数返回一个连接ID可用于断开 int connect(SlotType slot) { slots_.push_back(slot); return static_castint(slots_.size()) - 1; // 简单返回索引作为ID } // 通过连接ID断开 void disconnect(int id) { if (id 0 id static_castint(slots_.size())) { // 这里不能直接erase因为会改变后续元素的索引。 // 我们可以将其置为一个空函数或者使用一个更复杂的结构来标记“无效”。 slots_[id] nullptr; // 置空实际调用时跳过 } } // 发射信号 void emit(Args... args) { for (auto slot : slots_) { if (slot) { // 跳过被断开置空的槽 slot(args...); } } // 可选清理被置空的槽避免列表膨胀 slots_.erase( std::remove_if(slots_.begin(), slots_.end(), [](const SlotType s) { return !s; }), slots_.end()); } // 重载()操作符提供类似函数调用的语法 void operator()(Args... args) { emit(args...); } private: std::vectorSlotType slots_; };这个版本非常简洁。它使用std::functionvoid(Args...)作为统一的槽类型存储在std::vector中。connect返回一个整数IDdisconnect根据ID将对应的std::function置空emit遍历并调用所有非空的槽。使用示例#include iostream void freeFunction(int x) { std::cout Free function: x std::endl; } int main() { Signalint sig; // 连接自由函数 int conn1 sig.connect(freeFunction); // 连接Lambda表达式 int conn2 sig.connect([](int x) { std::cout Lambda: x * 2 std::endl; }); // 发射信号 sig.emit(42); // 输出两行 // 断开一个连接 sig.disconnect(conn1); sig.emit(100); // 只输出Lambda那一行 return 0; }3.2 基础版本的局限性这个“玩具”版本虽然能用但问题很多连接管理脆弱使用整数ID一旦我们清理了slots_向量比如在emit中移除空槽之前返回的ID就全部失效了指向错误的元素。这是一个严重的缺陷。不支持成员函数无法直接连接MyClass::memberFunc。没有自动断开如果槽函数捕获了一个对象的指针比如Lambda里用了[this]而这个对象后来被销毁了再次发射信号就会导致未定义行为悬空指针调用。性能每次emit都需要检查slot是否为空并且std::function的调用有一定开销。接下来我们要着手解决最紧迫的前两个问题。4. 进阶实现健壮的连接管理与成员函数支持4.1 改进连接句柄我们需要一个不受容器内部操作影响的连接句柄。一个常见的做法是使用std::shared_ptr或std::weak_ptr来管理每个槽的“存在性”。这里我们定义一个新的Connection类它内部持有一个std::weak_ptr指向信号内部为每个槽分配的控制块。class Connection { public: Connection() default; explicit Connection(const std::shared_ptrvoid tracker) : tracker_(tracker) {} // 判断连接是否还有效槽是否还存在 bool connected() const { return !tracker_.expired(); } // 手动断开连接 void disconnect() { tracker_.reset(); } private: std::weak_ptrvoid tracker_; // 类型擦除的弱引用 };在Signal内部我们不再直接存储std::function而是存储一个包含std::function和std::shared_ptrvoid的结构体。这个shared_ptr就是控制块当它被销毁引用计数为0时意味着这个连接在逻辑上“断开”了。connect方法会创建这个控制块并返回一个包装了其weak_ptr的Connection对象。4.2 支持成员函数连接为了连接成员函数我们需要在connect时绑定一个对象实例。我们可以提供一个重载的connect函数接受对象指针和成员函数指针。这里的关键是如何将obj-method(args...)的调用包装成一个std::functionvoid(Args...)。我们可以使用std::bind或者Lambda来捕获对象指针。templatetypename... Args class Signal { public: using SlotType std::functionvoid(Args...); // 连接普通函数对象Lambda, std::function等 Connection connect(SlotType slot) { auto tracker std::make_sharedint(0); // 控制块内容不重要重要的是shared_ptr本身 SlotHolder holder{std::move(slot), tracker}; slots_.push_back(std::move(holder)); return Connection(tracker); } // 连接成员函数 templatetypename T, typename Method Connection connect(T* obj, Method method) { // 使用Lambda捕获对象指针和成员函数指针 return connect([obj, method](Args... args) { (obj-*method)(args...); }); } void emit(Args... args) { // 遍历前先清理已失效的连接 cleanup(); for (auto holder : slots_) { if (holder.tracker.use_count() 0) { // 或者检查function是否可调用 holder.func(args...); } } } private: struct SlotHolder { SlotType func; std::shared_ptrvoid tracker; // 用于判断连接是否存活 }; std::vectorSlotHolder slots_; void cleanup() { slots_.erase(std::remove_if(slots_.begin(), slots_.end(), [](const SlotHolder h) { return h.tracker.use_count() 1; // 只有容器本身持有引用 }), slots_.end()); } };现在我们的Connection对象是可靠的。即使信号内部清理了失效的槽Connection对象通过检查tracker_.expired()也能正确报告连接状态。成员函数连接也得以支持。使用示例class Receiver { public: void onEvent(int value) { std::cout Receiver got: value std::endl; } }; int main() { Signalint signal; Receiver recv; // 连接成员函数 Connection conn signal.connect(recv, Receiver::onEvent); signal.emit(100); // 输出: Receiver got: 100 // 手动断开 conn.disconnect(); signal.emit(200); // 无输出 // 自动断开场景需要更复杂的生命周期管理见下文 { Receiver recv2; Connection conn2 signal.connect(recv2, Receiver::onEvent); signal.emit(300); // 输出: Receiver got: 300 } // recv2 离开作用域被销毁 signal.emit(400); // 理想情况应无输出但当前实现可能导致悬空调用 }如示例最后所示当recv2对象被销毁后我们仍然持有指向它的Lambda通过[obj, method]捕获。此时再发射信号就会调用一个已经销毁对象的成员函数这是灾难性的。我们基础的成员函数连接并没有解决自动断开的问题。5. 核心挑战对象生命期管理与自动断开这是实现一个健壮信号槽系统最复杂的部分。Qt依靠其元对象系统知道每个QObject的生死。我们的纯C实现没有这样的基础设施需要自己设计一套机制。5.1 基于std::weak_ptr的自动断开最符合现代C习惯的做法是要求接收对象必须由std::shared_ptr管理。我们的connect函数可以接受一个std::weak_ptrT和一个成员函数。在调用槽之前先尝试将weak_ptr提升为shared_ptr如果提升失败对象已销毁则跳过或移除该连接。templatetypename... Args class Signal { public: // ... 其他成员 ... // 连接由shared_ptr管理对象的成员函数 templatetypename T, typename Method Connection connect(std::weak_ptrT weak_obj, Method method) { // 这里我们创建一个SlotType它内部会检查对象是否存活 auto slot [weak_obj, method](Args... args) { std::shared_ptrT obj weak_obj.lock(); if (obj) { (obj-*method)(args...); } // 如果提升失败这个lambda什么也不做。 // 更好的做法是通知Signal这个连接已失效但这需要更复杂的交互。 }; // 我们需要一种方式当weak_obj失效时能自动清理这个slot。 // 一个技巧是将weak_obj的“失效回调”与连接关联。但这需要侵入weak_ptr或自定义智能指针。 // 更实用的方法是在每次emit时检查并清理所有失效的连接性能有损耗。 return connect(std::move(slot)); } };这种方法将生命周期管理的责任交给了std::shared_ptr/std::weak_ptr对使用者有侵入性必须用智能指针管理对象但实现相对清晰。在emit函数中我们仍然需要cleanup来移除那些因为对象销毁而永远无法再成功的槽。5.2 侵入式跟踪Trackable基类另一种经典模式是提供一个Trackable基类所有希望自动断开连接的对象都继承它。Trackable内部有一个唯一标识符如std::atomicint64_t生成的ID和一个标志如std::atomicbool或std::shared_ptrbool。当对象析构时将标志置为false。连接时不仅传递对象指针和成员函数还传递这个“存活标志”的weak_ptr。在槽函数调用前先检查标志。class Trackable { public: using AliveFlag std::shared_ptrbool; Trackable() : alive_(std::make_sharedbool(true)) {} virtual ~Trackable() { *alive_ false; } // 析构时标记为死亡 AliveFlag getAliveFlag() const { return alive_; } private: AliveFlag alive_; }; templatetypename... Args class Signal { public: templatetypename T, typename Method Connection connect(T* obj, Method method) { // 静态断言确保T继承自Trackable static_assert(std::is_base_ofTrackable, T::value, Class must inherit from Trackable for automatic disconnection); auto alive_flag static_castTrackable*(obj)-getAliveFlag(); auto slot [alive_flag, obj, method](Args... args) { if (*alive_flag) { // 检查对象是否还存活 (obj-*method)(args...); } }; // 我们需要在alive_flag所指的bool变为false时自动断开连接。 // 这可以通过将alive_flag与连接关联并在cleanup时检查来实现。 // 但更直接的是在SlotHolder里也保存这个alive_flag的weak_ptr并在调用前检查。 std::weak_ptrbool weak_flag(alive_flag); auto tracker std::make_sharedint(0); SlotHolder holder{std::move(slot), tracker, weak_flag}; // 新增weak_flag成员 slots_.push_back(std::move(holder)); return Connection(tracker); } private: struct SlotHolder { SlotType func; std::shared_ptrvoid tracker; std::weak_ptrbool objAliveFlag; // 对象存活标志的弱引用 }; void cleanup() { slots_.erase(std::remove_if(slots_.begin(), slots_.end(), [](const SlotHolder h) { // 连接失效的条件1. tracker唯一 或 2. 对象已死亡 bool trackerDead h.tracker.use_count() 1; bool objDead false; if (auto sp h.objAliveFlag.lock()) { objDead !(*sp); // 如果拿到了指针但标志为false } else { objDead true; // 连指针都拿不到了对象肯定死了 } return trackerDead || objDead; }), slots_.end()); } };这种方法要求对象继承自特定基类也有一定的侵入性但避免了强制使用shared_ptr。cleanup逻辑现在会同时检查连接句柄是否被放弃以及目标对象是否存活。实操心得在实际项目中侵入式Trackable和非侵入式shared_ptr两种方案各有优劣。如果项目代码结构允许继承Trackable可能更轻量。如果项目已广泛使用shared_ptr那么基于weak_ptr的方案更自然。你也可以同时提供两种connect重载让使用者选择。切记不要混合使用两种方式管理同一个对象的连接会导致混乱。6. 性能优化与线程安全扩展6.1 性能优化点内存分配每次connect都涉及std::function的构造和std::shared_ptr的控制块分配。对于高频连接的场景可以考虑使用内存池或小对象优化。遍历开销emit时需要遍历所有槽并检查有效性。如果槽数量很多cleanup和条件检查会成为瓶颈。可以考虑将“失效标记”与调用分离或者使用双缓冲区策略在emit时使用一个快照列表避免在遍历时修改原列表。std::function的开销std::function的调用有间接层。如果对性能有极致要求可以尝试使用模板化的槽存储利用C的编译期多态。但这会显著增加代码复杂度和编译时间。一个简单的优化是在Signal内部使用std::liststd::pairConnection, SlotType或类似结构来存储槽这样在断开连接时通过Connection对象可以以O(1)复杂度从列表中移除元素而无需在cleanup时遍历整个列表。Connection内部可以保存一个指向链表节点的迭代器。6.2 线程安全初步实现为了支持多线程环境下的连接和发射我们需要保护内部的slots_容器。一个粗粒度的做法是在connect、disconnect和emit函数中都加锁。#include mutex templatetypename... Args class Signal { public: Connection connect(SlotType slot) { std::lock_guardstd::mutex lock(mutex_); // ... 原有的连接逻辑 ... } void emit(Args... args) { // 关键在锁的保护下复制一份当前有效的槽函数列表。 std::vectorSlotHolder slotsCopy; { std::lock_guardstd::mutex lock(mutex_); cleanup(); // 清理需要在锁内进行 slotsCopy slots_; // 复制 } // 在锁外调用槽函数避免死锁。 for (auto holder : slotsCopy) { if (holder.tracker.use_count() 1) { // 检查复制品中的tracker holder.func(args...); } } } private: mutable std::mutex mutex_; // ... 其他成员 ... };重要警告上述线程安全实现是基础的但存在一个经典竞态条件在connect函数中我们创建SlotHolder并加入到slots_然后创建Connection。如果Connection的创建和返回在锁之外另一个线程可能在拿到Connection之前就发射信号导致它试图连接一个尚未完全加入列表的槽实际上由于Connection的创建依赖于slots_中的tracker这个操作必须在锁内完成。所以connect应该返回在锁内构造好的Connection。此外槽函数的执行线程是另一个大问题。上面的emit在调用槽时槽是在发射信号的线程中执行的。如果槽函数内部有耗时操作或访问了其他线程的数据可能会引发问题。Qt的QueuedConnection就是将调用请求打包成事件投递到接收对象所在线程的事件队列中。实现这个功能需要完整的消息队列和线程事件循环这超出了轻量级信号槽的范围。因此我们的线程安全版本应明确标注为“直接连接槽在发射线程同步执行”并提醒使用者注意槽函数的线程安全性。7. 常见问题与排查技巧实录在实现和使用自制的信号槽系统时你可能会遇到以下典型问题7.1 连接未生效或重复调用症状信号发射后槽函数没有被调用或者被调用了多次。排查检查连接返回值确认connect调用成功并保存了返回的Connection对象。如果Connection对象被立即销毁例如临时对象可能会导致连接刚建立就被断开如果Connection析构函数调用disconnect的话我们目前的实现没有这样做但某些库会。检查对象生命周期如果连接的是成员函数确保接收者对象在信号发射时仍然存活。使用我们基于Trackable或weak_ptr的方案可以在cleanup逻辑中加入调试输出查看连接是否因对象死亡被清理。重复连接我们的简单实现允许同一个槽被连接多次。如果你不小心连接了两次它就会被调用两次。如果需要唯一连接可以在connect内部检查是否已经存在相同的槽比较std::function对象比较棘手但可以比较对象地址和成员函数指针或要求使用者保证。7.2 程序崩溃悬空指针症状在信号发射时程序发生段错误或访问违例。排查这是最常见的原因接收者对象已被销毁但连接未断开。务必使用我们实现了自动断开机制的版本Trackable或weak_ptr。如果使用原始指针连接你必须手动管理生命周期在对象析构前断开所有连接。在槽函数中访问了无效数据即使对象本身存活槽函数内部访问的其他数据可能已失效。确保槽函数本身的逻辑是线程安全和生命周期安全的。信号对象本身被销毁后仍在发射确保发射信号的代码不会在信号对象析构后被调用。通常信号对象作为类的成员变量其生命周期应与所属对象一致。7.3 性能瓶颈症状程序运行变慢尤其是频繁发射信号的场景。排查与优化Profile使用性能分析工具如gprof, perf, VTune确定热点是否在信号槽的emit或cleanup中。减少槽函数数量审视设计是否每个连接都是必要的能否合并一些处理逻辑优化cleanup策略不要在每次emit时都清理。可以设置一个计数器每发射N次信号清理一次或者只在连接/断开时标记“脏位”在下次emit时清理。考虑无锁设计对于超高并发场景可以研究无锁队列来存储槽函数但这会极大增加实现复杂度。绝大多数情况下使用互斥锁并优化临界区范围已经足够。7.4 线程相关错误症状数据竞争、死锁或槽函数在错误线程中执行导致UI更新失败在GUI程序中常见。排查与解决明确线程模型你的信号槽是用于单线程、多线程发射单线程接收还是多对多我们的基础线程安全版本只保证了容器操作的线程安全不保证槽函数的执行线程。GUI编程如果你在类似Qt的GUI环境中使用自制信号槽更新界面必须确保更新UI的槽函数在UI线程主线程中被调用。这需要你将信号发射与UI线程调度耦合。在我们的系统中这通常意味着槽函数内部需要将实际工作post到UI线程的事件循环中而不是直接执行。避免死锁确保槽函数内部不要试图去锁定一个可能被信号发射线程锁住的资源。如果槽函数复杂尽量保持其不持有任何锁。实现一个完整的、生产级的信号槽库需要考虑的边界情况非常多比如信号槽的递归调用、阻塞连接、连接类型直接、队列、唯一连接等。但通过以上步骤我们已经构建了一个在单线程或明确线程边界下非常实用的、具备自动断开能力的C信号槽系统核心。理解了这个核心你就能根据具体项目需求进行裁剪、扩展和优化。
