signals and slots vs. virtual_hook (was [PATCH] KFileDialog overwrite confirmation)

[Michael Pyne]

On Monday 14 July 2008, Rafael Fernández López wrote:
> Hi there,
>
> In general, if we used the virtual_hook approach we would be having tons of
> benefits from my very point of view. Why ? All classes with virtual methods
> (at least, those which are very possible to grow when we need to assure
> binary compatibility) would count with a virtual hook and an enum. Is just
> a matter of checking the enum (that could be even called the same on all
> classes) when changing between BIG versions of KDE and see what we need to
> make virtual.


Well, we *do* use virtual_hook:


kde-svn at midna ~/kde4/kdelibs $ find . -name '*.h' -print0 | xargs -0 grep -l 
'void virtual_hook' | wc -l
47


I'm pretty sure it was even more extensively used in KDE 3.


Really the type of implementation is not really that big a deal though, the 
important thing is that it is possible.


If you already have virtual methods in your class adding virtual_hook() for 
future expandability does not hurt as you already have a vtable.  But if you 
forgot or chose not to then you can use signals/slots (or the d pointer) 
depending on whether you've derived from QObject or not.


At the end of the day though it's really just an implementation detail.  Maybe 
if there were numbers showing that one method should be preferred because it's 
one-two orders of magnitude faster (on code where the function call actually 
adds overhead too :P) we could say to prefer a method but we're not at that 
point yet.


Regards,
 - Michael Pyne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080714/3391a15e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080714/3391a15e/attachment.sig>