如何防止signals2::scoped_connection在断开()中中止？

Question

我使用的是boost::signals2 2，并且存在连接管理问题。我将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 ) );

ClientConnection：

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()时，我的结果是预取或数据中止。

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

Answer 1

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

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