Hi Jeff,
Thanks for the gory details :-) much appreciated; having said all that
the idea of having 'virtual' at the beginning of a method, and 'final'
at the end is (to me) pretty fugly but ... some great advice here.
Thanks ! :-)
Michael.
-------- Forwarded Message --------
From: Jeff Walden <jwal...@mit.edu>
To: michael.me...@suse.com
Subject: About Mozilla's final/override macros
Date: Mon, 28 Nov 2011 09:42:00 -0800
Via WordPress stats-webbug magic I see the final/override macros I added
to Mozilla are being discussed. A few details worth noting (feel free
to forward this to the list if you want):
GCC 4.7 (unreleased) and Clang 3 (unreleased, but on its nth RC) support
final/override. They require -std=c++0x or -std=gnu++0x to use
final/override without warning -- except that GCC also added a |__final|
extension, with the same use/semantics as |final|, which works
warning-free without -std=c++0x. (Beats me why they did this for |
final| but not |override|.) -Wno-c++0x-extensions disables the Clang
warning; I know no equivalent for GCC. I doubt you have people using
unreleased GCC for fun, but given the small but substantial Mozilla
developer base compiling with Clang trunk, I'd bet you have at least a
few people compiling LibreOffice with it.
MSVC supports final/override since the 2005 (!) release, but spelling it
|sealed| rather than |final| for now (C# bleed-over). Given that your
Windows build instructions talk about MSVC 2008, you probably have a
decent base of developers (and nightly build machines?) who'd test
final/override macros in your cross-platform code.
The static-analysis plugin was originally GCC-only but is now ported to
LLVM/Clang. final/override validation only occurred in a special
static-analysis build, not a normal developer or nightly build.
Static-analysis builds haven't happened recently, and in fact our
final-class annotations were flat-out wrong as a result! Clearly
compiler- and language-implemented analyses are much more trustworthy,
reliable, and less expensive in developer time (for projects, not for
the compilers) than user-driven analyses. Plus they happen in regular
builds on developers' machines. I personally don't see the benefit to
making our plugins check final/override annotations, but it could
happen.
The __attribute__() we used for final/override must appear in a position
different from the C++11 position. If you want both C++11 support *and*
static-analysis validation without requiring GCC 4.7 or Clang 3, you'd
need two macros, or one wrapping the entire declaration.
#define OVERRIDE_METHOD(decl) __attribute__(...) decl override
class Foo
{
OVERRIDE_METHOD(virtual void foo());
};
I dunno about you, but I would call this much worse "hideous ugliness"
than just appending OVERRIDE or whatever after the declaration, and
giving up on plugin-based validation until distro releases including GCC
4.7 saves you.
Anyway, hope that helps.
Jeff
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
