[Development] RFC: banning _q_slot() in favour of new-style connect()?

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121012/ec1cecbd/attachment.sig>