thiago at kde.org
Thu Jan 11 16:14:16 GMT 2007
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:
>>> Q_PRIVATE_SLOT(d, void slotDateChanged())
>>> KDateWidgetPrivate *d;
>>How is this better than the following?
>> 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
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
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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel