== Why is this an issue?

Since ``++final++`` classes can't be extended, indicating that functions in such a class are overrideable by adding the ``++virtual++`` specifier is possibly misguided, and definitely confusing.


=== Noncompliant code example

[source,cpp]
----
class Base {
  virtual void f1();
};

class C final : Base {
  virtual void f1();  // Noncompliant
  virtual void f2();  // Noncompliant
};
----


=== Compliant solution

[source,cpp]
----
class Base {
  virtual void f1();
};

class C final : Base {
  void f1() override;
  void f2();
};
----


== Resources

* S3471 - "override" or "final" should be used instead of "virtual"



ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Remove this "virtual" specifier or replace by "override".


=== Highlighting

``++virtual++``


'''
== Comments And Links
(visible only on this page)

=== relates to: S2156

=== relates to: S3471

=== on 29 Jun 2016, 21:19:32 Ann Campbell wrote:
FYI [~evgeny.mandrikov] RuleAPI will automatically convert S\d+ into the format the platform needs to form a link to a rule.

=== on 11 Jul 2016, 22:05:03 Ann Campbell wrote:
\[~alban.auzeill] you don't have to insert the rule-link syntax. That's handled for you by RuleAPI

=== on 11 Jul 2016, 22:22:55 Alban Auzeill wrote:
@Ann I'm doing several tests to try to find a temporary solution to the following problem: First, we generate the description of a rule using rule-api with the option "-language c". Then we use this description for C,{cpp},ObjC, and for example "S3471" will always be transformed to \{rule:c:S3471\} even if I need \{rule:cpp:S3471\}


But, yes, at the end "S3471" is perfect once I have implemented the generation of the 3 languages separately...but it's not yet the case.

endif::env-github,rspecator-view[]
