On sexta-feira, 12 de outubro de 2012 12.08.59, Marc Mutz wrote: > > True, but minimal impact. > > QLineEdit has up to seven _q_ slots, vs. up to eight normal ones (exact > number depends on #ifdefs). But yes, I need to measure whether the > reduction in the meta-object isn't offset by the extra code for another > QSlotObjectBase subclass. > > So I replaced one of the _q_ slots in QLineEdit with a functor. Result: > > text data bss dec hex filename > 6356969 296120 2712 6655801 658f39 lib/libQtWidgets-new.so.5.0.0 > 6356959 296184 2712 6655855 658f6f lib/libQtWidgets.so.5.0.0 > > (text + 10, data - 64) > > relinfo results are identical between the two.
So, like I said, minimal impact :-) > > > Gotchas: > > > G1. The slot could have been overridden in a more-derived class > > > > Extremely unlikely, which is why they have a _q_ prefix in their names. > > I'm not talking about accidental reimplementations, but intentional ones. Ah, I see. Still unlikely, though. > > > G2. The Private pointer could change in between the connect() and the > > > emit. Currently, this is transparently handled by injecting a call to > > > d_func() into the moc-generated code. For new-style connect, such a > > > situation would require a disconnect/connect pair. > > > > That's even more unlikely to the point I can confidently say it never > > happens. (remember Q_PRIVATE_SLOT is a private macro, so no one outside of > > Qt is using it) > > QDBusConnectionPrivate::deliverCall does something 'funny' with > QDBusContextPrivate (::set()), but I didn't look too deeply into it. I don't think it affects anything. QDBusContext isn't a QObject class: it can't be, since you're supposed to multiply-inherit from it along with your QDBusAbstractAdaptor. > Anyway, I've used Q_PRIVATE_SLOT in all kinds of projects, including KDE, so > it's not like no-one outside of Qt is using it. Those don't count. Since the macro is private, we're allowed to disregard everyone using it outside of Qt. Therefore, we can say that no one else is using them. > > If we agree on how to use them, yes. The only solution we *can* use is > > functors, which are hard to use. > > Not harder to use than Q_PRIVATE_SLOT, IMO. More annoying, yes, because of > boilerplate code (of which Q_PRIVATE_SLOT also has some, mind). Real-life > example: [snip] I'd rather explore options like what Olivier is proposing. The functors, as you showed, all need to keep a pointer to the original object, which QObjectPrivate already carries. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development