On sábado, 15 de dezembro de 2012 05.46.39, Nikos Chantziaras wrote: > On 15/12/12 05:19, Thiago Macieira wrote: > > On sábado, 15 de dezembro de 2012 03.45.56, Nikos Chantziaras wrote: > >> So I take it that means we should always manually disconnect in such > >> cases. Thinking about it, it seems possible to have done this > >> automatically, but only for QObjects and through a connect() function > >> > >> that would accept: > >> connect(const QObject* sender, PointerToMemberFunction signal, > >> > >> const QObject* receiver, Functor functor); > >> > >> In that case, connect() would be able to know when 'receiver' gets > >> destroyed and automatically do a disconnect. > > > > It automatically disconnects when the destruction reaches the QObject > > destructor. > > Which QObject destructor? The receiver is being destroyed before the > sender:
The receiver's. If the signal is emitted *during* the receiver's destruction,
you have to analyse this case.
> class Foo: public QObject {
> Q_OBJECT
> public:
> Foo(QObject* obj)
> {
> QObject::connect(obj, &QObject::objectNameChanged,
> [this](const QString& objectName) {
> ++this->i;
> });
> {
>
> int i = 0;
>
> //...
> };
>
> // ...
> Foo* foo = new Foo(someQObjectPtr);
> delete foo;
>
> So how does the destructor of Foo know how to disconnect when foo is
> deleted?
I don't see your point. QObject::connect adds the connection object to a list.
QObject::~QObject destroys the list.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
