Re: [lmi] [PATCH] Use C++11 override keyword

[Greg Chicares]

On 2016-07-31 21:58, Vadim Zeitlin wrote:
> 
>  Here is the patch for the next step of C++11-ization which adds "override"
> keywords in all places where they should be used, i.e. whenever a class
> redeclares a virtual function of a base class:
> 
>                   https://github.com/vadz/lmi/pull/46
> 
> The patch is huge but should hopefully be uncontroversial as all the
> changes are very similar. And it's worth doing this because accidentally
> not overriding a virtual function that was meant to be overridden is a
> relatively common error, so it's nice to let the compiler detect it

Consider:

-    ~configurable_settings();
+    ~configurable_settings() override;

Is it normal to write "override" on a dtor that's forced to be virtual
because a base class (xml_serializable<configurable_settings> in this
case) has a virtual dtor? Maybe I'm just stuck on the word "override",
which suggests displacing one thing in favor of another--which is
exactly what happens here:

-    virtual int                class_version() const;
+    int                class_version() const override;

where xml_serializable::class_version() is not called (and wouldn't be
called even if it weren't 'pure'). But ~xml_serializable() is not
displaced at all: rather, it's chained to.

Well, I guess it's like Humpty Dumpty's dialogue with Alice--the word
means just what they choose it to mean:

  [10.3/6]
| Even though destructors are not inherited, a destructor in a derived
| class overrides a base class destructor declared virtual

>  The only niggling doubt I have is whether we should have kept the
> "virtual" keyword too instead of dropping it. E.g. consider class
> AboutDialog:

-     virtual int ShowModal();
+     virtual int ShowModal() override;
versus
+     int ShowModal() override;

My initial impression is that it's better to drop the redundant
'virtual' as you have done. Its only purpose was to make the virtual
nature explicit, and 'override' does the same thing. One is written
after the function name, and the other before, but we already have
such variation, e.g.:

  virtual void foo() = 0;
  ^^^^^^^           ^^^^
  before           after