Thiago, thanks for the patch! As you've noted in the comments to the patch yourself, it doesn't quite work. I also would understand if you're reluctant to add changes to such a central part of Qt. The new templated connect already has a tendency to produce verbose and noisy error messages if you mistype.
Olivier, I think your suggestion with addDeleteWatcher() is the most precise. It would completely satisfy my original wish elegantly, without requiring any radical changes: QObject::connect(sender, &QLineEdit::editingFinished, std::bind(&QWidget::setWindowModified, receiver, true)).addDeleteWatcher(receiver); Sorry about the XY thing, but at least you were completely able to understand my intentions;) Thanks for the suggestions. Björn 2013/5/4 Olivier Goffart <oliv...@woboq.com> > > On sexta-feira, 3 de maio de 2013 11.50.14, Björn Piltz wrote: > > > Would it be possible to add an overload of QObject::connect() like > this: > > > > > > static QMetaObject::Connection connect(const QObject *sender, > > > PointerToMemberFunction signal, const QObject *receiver, Functor > > > functor); > > > > > > in addition to > > > > > > static QMetaObject::Connection connect(const QObject *sender, > > > PointerToMemberFunction signal, Functor functor); > > Hi, > > I would say this is an instance of the XY problem: > http://meta.stackoverflow.com/questions/66377/what-is-the-xy-problem > > Why would you want to have a 'receiver' when there is no really a receiver? > > Another question i often see is why don't we accept non-QObject receiver. > > Appart from being the object which owns the member function, the QObject > receiver also get used for those features: > - The connection is automatically disconnected when the receiver is > destroyed. > - The thread affinity of the object is used to possibly perform a queued > connection in the thread of the receiver > - The receiver's sender() and senderSignalIndex() are updated. > > Those features are totally valid use case you may want for lambda > functions, > and I agree we should support that. I had that in mind with several ways > to > solve it, but it was not implemented in Qt 5.0 because i left that for > later. > > Here are some way to solve it: > > 1) add new overloads of QObject::connect with 5 arguments that takes > functor > as parametters with a receiver. > > Code would look like this: > connect(obj1, &Foo::theSignal, obj2, [&]() { obj3->doSomething(obj2); > }); > > This is easy to do with C++11 variadic template, a bit more difficult if > you > only have decltype and C++11 revisited SFINAE, and even more difficult if > you > can't use C++11 at all. > > But here the problem is semantic. With a lambda function, we dont have a > "receiver" anymore. Also, why are we limited to one receiver? > > > 2) Since we now return a QObject::Connection, we can add API on that class. > For example: > > auto c = connect(obj1, &Foo::theSignal, [&]() { obj3->doSomething(obj2); > }); > c.addDeleteWatcher(obj2); > c.addDeleteWatcher(obj3); > c.queueInThread(obj2.thread()); > > Implementation of this would be trivial. > > Other syntaxes are possible: > connect(obj, ..., [&]() { ... } ).setReceiver(obj2); > > The challenge is thread safety. (what if the signal is emitted in another > thread before we set the receiver?) > > 3) for deletion purpose, maybe having a kind of scoped pointer around > QObject::Connection > > obj2->m_connections.track(connect(obj1, ..., [] {...} )); > > it could also be an API in QObject itself > obj2->trackConnection(connect(obj1, ..., [] {...} )); > > > > I'm tempted to say that the new QObject::connect overloads are not that bad > after all. > > -- > Olivier > > Woboq - Qt services and support - http://woboq.com - http://code.woboq.org > >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
