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
otherfile.cpp:10)
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))
#else
# define KDE_DEPRECATED
#endif
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.
Zack
--
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