公共 boost::信号对象

发布于 2024-07-14 09:44:03 字数 308 浏览 12 评论 0原文

我公开我的 boost::signal 因为我很懒。

class Button {
public:
    signal<void()> clicked;
};

int main() {
    Button btn;
    btn.clicked.connect(handleClick);
}

...而不是用 Button::OnClicked(boost::function) 封装。

它会回来咬我吗?

I make my boost::signals public because I'm lazy.

class Button {
public:
    signal<void()> clicked;
};

int main() {
    Button btn;
    btn.clicked.connect(handleClick);
}

... rather than encapsulating with a Button::OnClicked(boost::function<void()>).

Is this going to come back and bite me?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

冷…雨湿花 2024-07-21 09:44:03

这取决于。

以前当我想在每次一个对象连接到另一个对象的信号时添加一些特殊的逻辑时,它就困扰着我。 这是最有可能咬你的情况。

此外,它还使得准确跟踪其他对象何时连接到任何给定对象变得困难。

为了安全起见,我想说将连接隐藏在函数后面。

我通常使用宏来进行普通函数定义。

#define SIGNAL(slot,name) connection name(function<slot> func) { return _##name##.connect(func);}

然后在类定义中:

SIGNAL(void(),clicked)

这假设您遵循命名信号“_clicked”的约定,但您可以替换任何约定。 它通常使所有类的界面保持干净。 当您想要添加特殊的连接逻辑时,您可以添加特殊的连接逻辑,而无需更改使用该信号的所有其他对象。

编辑

一个实例是信号对象实际上被移动到另一个类内的委托实现,但对象通过原始类进行连接仍然有意义。 这破坏了所有尝试连接到它的地方。 如果他们一直使用函数访问器进行连接,那么就像更改函数以在委托中查找信号一样简单。 但事实上它破坏了原始类别的所有用户。

或者,当我想记录每次连接到特定信号的东西时。 这仅用于调试目的,但如果您怀疑信号连接中出现了奇怪的情况(例如循环),它会非常有帮助。

It depends.

It has bitten me before when I wanted to add some special logic each time an object connected to another object's signals. This is the most likely case to bite you.

Also, it can make it difficult to keep track of exactly when other objects are connecting to any given object.

I would say hide the connections behind a function to be on the safe side.

I usually use a macro to do the vanilla function definition.

#define SIGNAL(slot,name) connection name(function<slot> func) { return _##name##.connect(func);}

And then in a class definition:

SIGNAL(void(),clicked)

This assumes you follow the convention of naming the signal '_clicked' but you can substitute any convention. It generally keeps the interface cleaner for all of your classes. When you want to add special connection logic you can, without changing all of the other objects that use the signal.

EDIT

One instance was when the signal object was actually moved to a delegate implementation inside another class, but it still made sense for objects to connect through the original class. This broke all of the places that tried to connect to it. If they had been using function accessors to connect, it would have been as simple as changing the function to look up the signal in the delegate. But as it was it broke all the users of the original class.

Or, when I wanted to log each time something connected to a specific signal. This was just for debugging purposes, but it can be very helpful if you suspect something wonky is going on like cycles in your signal connections.

桃气十足 2024-07-21 09:44:03

我偶然发现了一个不这样做的好理由。

我们正在考虑使用在外部接口上公开 boost::signals 的第三方库。 该库依赖于带有一组编译器定义的 boost 版本,这些编译器定义与我们在项目中使用的标准 Visual Studio 编译器定义二进制不兼容。 每当我们尝试调用第三方库的 signal.connect 时,事情就会消失。

我们的解决方案是:

  1. 使用它们提供的 boost 版本重新编译所有源库和依赖库。
  2. 包装升压信号并隐藏实现

至少需要考虑一些事情!

I've stumbled across a good reason not to do this.

We are looking at using a third party library that exposes boost::signals on an external interface. This library depends on a version of boost with a set of compiler definitions that are binary-incompatible with the standard Visual Studio compiler definitions that we use in our project. Whenever we attempt to call the third-party-library's signal.connect, things die.

The solution for us is either to:

  1. Recompile all of our source and dependent libraries with the boost version provided by them.
  2. Wrap the boost signals and hide the implementation

Something to consider, at least!

一杯敬自由 2024-07-21 09:44:03

好吧,这个问题确实与 boost::signal 或 function 无关 - 这都是关于封装的。

Button 类的客户端是否需要完全访问clicked? 如果他们应该能够做的就是订阅它,那么仅允许使用 OnClicked 方法进行订阅。 恕我直言,暴露更多可能可能会咬你一口。

一如既往,您要平衡成本与收益。 在这种情况下,成本非常低。 如果您是我的团队成员,我强烈建议您添加 OnClicked 方法。

Well, this questions really has nothing to do with boost::signal or function - it's all about encapsulation.

Do client's of the Button class need complete access to clicked? If all they ought to be able to do is subscribe to it then allow only that with the OnClicked method. Exposing more than that is likely to bite you IMHO.

As always you balance costs vs benefits. In this case the cost is very low. If you were on my team I'd strongly recommend you add the OnClicked method.

眼中杀气 2024-07-21 09:44:03

我也将它们设置为公开,并使用大驼峰式作为其对象名称。 这种方法从来没有对我产生适得其反的效果。

I set them public as well and use upper-camel-case for its object name. This approach never backfired on me.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文