[Libreoffice] [Fwd: About Mozilla's final/override macros]

[Michael Meeks]

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 <jwalden at MIT.EDU>
To: michael.meeks at 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.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot