private slots

[Thiago Macieira]

Thiago Macieira wrote:
>Thomas Zander wrote:
>>On Wednesday 03 January 2007 16:05, Simon Hausmann wrote:
>>> This slot is not intended for applications to call/use and it is
>>> connected to the internal widgets. There's no need to have it in the
>>> public API and exported. You can use the following instead:
>>>
>>> ...
>>> private:
>>>     Q_PRIVATE_SLOT(d, void slotDateChanged())
>>>
>>>     KDateWidgetPrivate *d;
>>> ...
>>
>>How is this better than the following?
>>
>>private slots:
>>    void slotDateChanged();
>
>That's still a member function and subject to #define private public.
>Friends can also call it.
>
>The most benefit comes when the Private class is more than just a big
>struct with member fields: when you actually write code in it.

I have one more reason why the Q_PRIVATE_SLOT is better than a slot that 
is private:

The public class is exported, the private one isn't. Until g++ makes all 
private symbols for friendless classes hidden by default, this accounts 
for a huge impact in the relocation.

The moc-generated code must call the slot function when it receives a 
signal being dispatched. If it calls a function that isn't exported, the 
compiler and linker can enter an agreement and simply generate a 
PC-relative branch.

If, instead, the call is made to a function that is exported, the compiler 
must instead branch to a PLT stub, which means relocation. This is 
necessary because, in theory, another library could override the symbol.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070111/68dfcd14/attachment.sig>