By far I've encountered the same problem. The document in boost web says that the disconnection occurs when 'An object tracked by the slot is destroyed.', however, I tested it doesn't work in that way. So I prefer to disconnect manually although it's little bit troublesome.
My test code :
class MySignal {
public:
boost::signals2::signal<void ()> signal_one;
boost::signals2::signal<void ()> signal_two;
};
class MySlot {
public:
void SlotOne() {
std::cout << "slot_one" << std::endl;
}
void SlotTwo() {
std::cout << "slot_two" << std::endl;
}
};
int main() {
MySignal signal;
auto* slot = new MySlot;
auto c = connect(signal.signal_one, slot, &MySlot::SlotOne);
// c.disconnect();
if (slot != nullptr) {
delete slot;
slot = nullptr;
}
signal.signal_one();
return 0;
}
Can anybody tell me why the slot can still be triggered while I already destroyed the slot object?
I can only convince myself that the boost's document says the 'disconnection' can occur under some circumstances but doesn't say it will happen automatically.
Words below are what the boost document says:
Signal/slot disconnections occur when any of these conditions occur:
1.The connection is explicitly disconnected via the connection's disconnect method directly, or indirectly via the signal's disconnect method, or scoped_connection's destructor.
2.An object tracked by the slot is destroyed.
3.The signal is destroyed.
Aucun commentaire:
Enregistrer un commentaire