调试Qt信号和插槽有哪些最佳实践?

Ral*_*zky 4 debugging connection qt signals-slots

调试信号和插槽可能很难,因为调试器在发出时不会跳转到信号的插槽.调试Qt信号和插槽有哪些最佳实践?

特别是

  1. 如何确保成功建立连接?
  2. 我何时应该使用信号和插槽,何时应该避开它们?
  3. 根据您的经验,最有效的调试技术是什么?

jdi*_*jdi 6

有一篇博客文章写了一段时间后调用了20种调试Qt信号和插槽的方法
它解决了我认为问题的#1和#3.

对于#2,我认为使用或不使用信号/插槽确实存在硬性和快速的原因,因为它们是GUI框架的一个非常核心的概念.信号是将一个组件的知识与另一个组件分离的完美方式,允许您设计可重用的小部件,只需声明状态更改或通知.通过发出主线程可以看到的信号,它也是从非GUI线程循环传递GUI更改的一种非常好的方法.

可能有时候你真正想要的而不是信号/槽是使用事件,例如当父窗口小部件应该成为许多子窗口小部件的事件过滤器时.孩子们仍然不需要了解父母,父母获得更直接的事件而不是信号连接.

在同一个事件主题上,有时候你真正想要的是从孩子那里冒出一个事件 - >父母 - >祖父母 - >等等.信号在这里没有意义,因为它们不是一种确定方式拟议的事件是否应该导致行动(显然可以这样使用).事件允许您检查当前状态,确定此窗口小部件是否应该执行任何操作,或以其他方式将它们冒出来以供其他人检查.

关于信号/插槽和事件之间的差异,有一个非常棒的答案.这是一个很好的片段:

  • 你"处理"事件
  • 您"收到"信号发射的通知

我喜欢这句话的是它描述了不同的需求案例.如果您需要在窗口小部件中处理操作,那么您很可能想要一个事件.如果您想收到有关事情发生的通知,那么您可能需要一个信号.

  • 您提供的链接在实际调试技术方面相当平庸.要点基本上是:*"避免编写错误,这里有20件可能出错的事情"*.没有提到实际调试问题的工具或技术.当你遇到崩溃转储时,你会遇到一个疯狂的深度callstack,很多`qt_static_metacall`调用,没有简单的方法来破译发出的信号,而且根本无法知道,在哪里建立任何特定的信号槽连接. (4认同)