Extending moc (small thing)

Zack Rusin zack at kde.org
Sat Dec 28 08:28:03 GMT 2002

Hi everyone,

I extended moc parser a little bit to allow an identifier after the 
method declaration. 

The obvious question would be "why?". Well, for example gcc 3.2 allows 
one to mark functions as deprecated. Every time an application calling 
the deprecated function is used a warning of the form
file.cpp:16: warning: `func' is deprecated (declared at 
is generated, which I figured would be mightely helpful for us. So we 
could have a macro like:
#if __GNUC__ >= 3 && __GNUC_MINOR__ >= 2
#  define KDE_DEPRECATED __attribute__((deprecated))
And then for example in kaction.h, the deprecated plugAccel function 
would look like:
virtual void 
plugAccel(KAccel *accel, bool configurable = true) KDE_DEPRECATED;

This would lead to a lot faster spotting of deprecated code. 

The problem is that moc chokes on the above presented construct, so I 
let it accept an optional identifier after the method signature. The 
"deprecated" is not the only attribute we could use "noreturn", 
"noinline", "always_inline" and "pure" are examples of others that we 
could find useful. The moc.y patch is attached (includes fix for two 
missing semicolons in moc.y, but I figured since it's only three lines 
long you won't mind).

I just wanted to know what are your opinions about that as personally 
I'd love to have a compile time indication of deprecated functions.


C.O.B.O.L - Completely Obsolete Boring Old Language.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: moc.diff
Type: text/x-diff
Size: 1083 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021228/8dcf8007/attachment.diff>

More information about the kde-core-devel mailing list