private slots

[Simon Hausmann]

Hi,

while we're on the topic of public APIs and kdelibs cleanups: Here's a neat 
little moc trick that we use in Qt 4 and that we can very well also use in 
kdelibs.

It is very common to need slots in public classes. Take KDateWidget for 
example:

...
protected Q_SLOTS:
  void slotDateChanged();
...
private:
    KDateWidgetPrivate *d;
...

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;
...

This macro expands to nothing but moc reads it nevertheless. It will generate 
a slot with the given signature in the metaobject, so you can connect to it. 
But it assumes that the method itself is a member function of the first 
argument of the macro. So the generated code will look like

... [deep in the metacall ]
	d->slotDateChanged();
...

If that moc generated code is included from within the .cpp file (like we 
fortunately do most of the time in KDE) d is well-defined and the compiler 
can call your private slot, which is now just a member function of your d 
pointer.

And of course in general I suggest not to have any private methods in our 
public API at all. Putting it into your d-pointer gives you more flexibility 
in the future to change the implementation. There is really no good reason 
for exporting private functions.

I've heard gcc 4.2 will apply the default (hidden) visibility to private 
members, so they won't exported anymore. But I hope that at some point in the 
future we can provide binary compatibility in kdelibs with more than just gcc 
> 4.2 :)


Simon
-------------- 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/20070103/8a144252/attachment.sig>