Well, I can get you a very helpful statement - Qt is open source. Take its sources and see when disconnectNotify() is being called. It only takes a couple of seconds to grep them for "disconnectNotify(".
It won't be invoked. It's invoked only when disconnect() is being called which doesn't happen when an object is destroyed.I connect a QLineEdit's setText-slot to the TestObject's textChanged-signal. Then I destroy the QLineEdit. Then I expect the TestObject's disconnectNotify method to be invoked. This doesn't happen.
The method does exactly what it says - it notifies you when "disconnect" is being called. I understand that it would be neat to have this information also when objects are destroyed but then you fall into the problem I pointed out at the beginning - a virtual method being called from a destructor. Of course you could make a check and call the method only if it is the receiver that gets destroyed but then the behaviour would still not be coherent and one could argue that if you can't signal in both cases then you shouldn't signal in either case. This is a problem you cannot solve. I can agree that maybe the documentation for the method should point this out but then maybe it should also point out the fact you need to have a compiler to use this method. Let's be explicit about everything everywhere. So what that this would make the docs completely useless but at least it would be useless in every case which is good, right?I expect that, because I learned 30 years ago, that a method's name is a promise.
Bookmarks