0

我正在使用 boost::signals2 并且有连接管理问题。我将 scoped_connections 存储在稍后修剪的列表中。但是，我发现如果拥有相关信号的对象已被销毁，则 scoped_connection::disconnect() 会中止，因为它的几个字段现在无效。

signals2::connection conn =
    client->connectRequest( RequestSignal::slot_type(
        bind( &Manager::requestRefresh, this, _1 ) ).track( client ) );
mClients.push_back( ClientConnection( client, conn ) );

客户端连接：

struct ClientConnection
{
    weak_ptr<Client> client;
    signals2::scoped_connection* connection;

    ClientConnection( weak_ptr<Client> aClient, signals2::connection aConnection )
    {
        client = aClient;
        connection = new signals2::scoped_connection( aConnection );
    }

    ~ClientConnection()
    {
        delete connection;
    }
}

Manager 类拥有这些 ClientConnections 的列表，并定期迭代并尝试删除无法从中获取合法 shared_ptr 到客户端的条目。我现在了解到 track() 在对象过期时不会断开连接，就像我想象的那样；它只是阻止信号发射。当客户端超出范围时，scoped_connection 最终会指向一堆坏内存，并且在执行 disconnect() 时会出现预取或数据中止。

我忽略的信号2 API中有什么可以纠正这个问题吗？还是我必须重新考虑我的连接管理？我知道必须从这一端保持与客户端信号的连接似乎很奇怪，但是客户端消耗的流可能超出范围，因此在这种情况下，我需要断开管理器的插槽与客户端的连接。

4

1 回答 1

0

事实证明，这是一个对象生命周期问题，而不是信号 2 问题。我使用一个指向作用域连接的原始指针来绕过它的不可复制属性。但是我忽略的是，当结构在插入列表时被复制构造时，原始结构被破坏，从而删除了指针的内存......

将其更改为共享指针可解决此问题。

于 2016-05-25T14:34:47.250 回答