Boost::Signals 有什么意义？
首先，我是一个绝对的编程初学者，所以不要太取笑我。
我所见过的信号唯一的用途是 GUI 工具包，而 GUI 工具包都带有自己的信号。那么，Boost:Signals 是否可以与这些 GUI 工具包一起使用？这是个好主意吗？信号还有哪些其他应用？
Firstly, I am an absolute beginner in programming, so don't make fun of me too much.
The only thing that I have seen signals used for are GUI toolkits, and GUI toolkits all come with their own signaling. So, can Boost:Signals even be used with these GUI toolkits? Would this be a good idea? What other applications do signals have?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Signals 是一种事件消息传递实现，很像 Smalltalk/Objective C Messages 或各种其他（例如 C#）语言中的 Events。
您可以将它们用于各种任务，请查看观察者模式
为什么要 使用它们使用观察者模式？
好处主要是组织性的，当您使用大型应用程序时，应用有助于保持开发团队一致性的重用模式非常重要。
当特定模式的实现成为事实（或接近）时，它特别有用，因为这意味着新团队成员的准备时间可能会加快，不仅因为他们以前使用过该实现，而且还因为流行实施的成功将意味着有广泛的资源和文档可用于加速学习。
从纯代码的角度来看，所有模式都显得臃肿，但是当您开始了解软件开发中 60% 以上的成本都在维护生命周期中时，额外的代码来获得一致性是非常值得的。
另一个好处是有助于软件重用，根据实现的风格，观察者模式可以帮助模块化和类之间的解耦。我认为这也是一种组织优势，因为不同的团队可以更轻松地构建组件，或者仅仅是因为组件更容易替换。
Signals is an event messaging implementation, much like Smalltalk/Objective C Messages or Events in various other (e.g. C#) lanugages.
You can use them for a wide variety of tasks, take a look at the Observer Pattern
Why would you use the Observer Pattern?
The benefits are largely organisational, when you work with large applications it's is important to apply patterns of reuse that help maintain development team coherence.
When the implementation of a particular pattern becomes de facto (or close to) it's especially useful because it means that lead up times for new team members are likely to be expedited, not only if they have used the implementation before, but also because the popularity of the implementation will mean that there are widespread resources, and documentation available to speed learning.
From a pure code perspective, ALL patterns appear as bloat, but when you begin to understand that upwards of 60% of the costs involved in software development are in maintenance life-cycle, it is well worth the additional code to gain coherence.
The other benefit is to aid in software reuse, depending on the style of implementation, the Observer Pattern can assist in modularising and decoupling classes from one another. I would suggest that this is also an organisational benefit, in as much that different teams can build components more easily, or simply because components are easier to replace.
只是我的两分钱，信号不仅用于（或用于）GUI 工具包。它们用于想要将数据的生成者与其接收者解耦的上下文（例如上面提到的观察者模式）。如果你将这个想法与线程相结合，你可以轻松地实现参与者，这是并发任务的一个有趣的模式（例如，Erlang 和 Scala 使用参与者）。
Just my two cents, signals are not only used in (or for) GUI toolkits. They are used in contexts where you want to decouple the producer of a datum with the receiver of it (the observer pattern mentioned above, for example). If you mix that idea with threads, you can implement actors easily, an interesting pattern for concurrent tasks (Erlang and Scala use actors, for instance).
一种可能的用途是实现 GUI 工具包。您基本上会设置连接以从本机系统获取消息（或它们碰巧被调用的任何内容）以产生信号。从那里，用于路由和处理信号的代码可以（至少在某种程度上）可移植。
One possible use would be in the implementation of a GUI toolkit. You'd basically set up the wiring to get messages (or whatever they happen to be called) from the native system to produce signals. From there, the code for routing and handling signals can be (at least somewhat) portable.
除了其他人提到的观察者模式之外，任何时候您发现自己必须编写回调函数，以便一个类可以通知另一个类发生了某些事情，那么您可以使用信号和槽来代替。相对于回调的巨大优势在于，它会处理大量样板代码来添加和删除回调函数，并在调用者或被调用者超出范围时处理自动断开连接。
不过，回调实际上只是观察者模式的一个实例。
In addition to the Observer pattern that others have mentioned, anytime you find yourself having to write a callback function, so that one class can notify another that something has happened, then you can use Signals and Slots instead. The great advantage over callbacks is that it takes care of lots of the boiler plate code to add and remove the callback function, and deals with automatically disconnecting when either the caller or the callee go out of scope.
Callbacks are really just an instance of the Observer pattern though.