Quel est le but du mot-clé "final" en C++11 pour les fonctions ?

Question

Quel est le but du mot-clé final en C++11 pour les fonctions? Je comprends qu'il empêche le remplacement de fonction par les classes dérivées, mais si tel est le cas, ne suffit-il pas de déclarer vos fonctions final comme non virtuelles? Y a-t-il autre chose que je rate ici?

Answer 1

Ce que vous manquez, comme idljarn l'a déjà mentionné dans un commentaire, c'est que si vous remplacez une fonction d'une classe de base, alors vous ne pouvez pas la marquer comme non-virtuelle :

struct base {
   virtual void f();
};
struct derived : base {
   void f() final;       // virtuelle car elle remplace base::f
};
struct mostderived : derived {
   //void f();           // erreur : impossible de remplacer !
};

Answer 2

• Il sert à empêcher une classe d'être héritée. De Wikipedia :

  C++11 ajoute également la possibilité d'empêcher l'héritage de classes ou simplement d'empêcher la redéfinition de méthodes dans les classes dérivées. Cela se fait avec l'identifiant spécial final. Par exemple :

  struct Base1 final { };
  
  struct Derived1 : Base1 { }; // incorrect car la classe Base1 
                               // a été marquée comme final

• Il est également utilisé pour marquer une fonction virtuelle afin de l'empêcher d'être redéfinie dans les classes dérivées :

  struct Base2 {
      virtual void f() final;
  };
  
  struct Derived2 : Base2 {
      void f(); // incorrect car la fonction virtuelle Base2::f a 
                // été marquée comme final
  };

Wikipedia fait en outre une observation intéressante:

Notez que ni override ni final ne sont des mots-clés du langage. Ce sont techniquement des identifiants; ils acquièrent un sens spécial uniquement lorsqu'ils sont utilisés dans ces contextes spécifiques. Dans tout autre contexte, ils peuvent être des identifiants valides.

Cela signifie que ce qui suit est autorisé :

int const final = 0;     // ok
int const override = 1;  // ok

Answer 3

"final" permet également à un compilateur d'optimiser en contournant l'appel indirect :

class IAbstract
{
public:
  virtual void DoSomething() = 0;
};

class CDerived : public IAbstract
{
  void DoSomething() final { m_x = 1 ; }

  void Blah( void ) { DoSomething(); }

};

avec "final", le compilateur peut appeler CDerived::DoSomething() directement depuis Blah(), ou même l'incorporer en ligne. Sans cela, il doit générer un appel indirect à l'intérieur de Blah() car Blah() pourrait être appelé dans une classe dérivée qui a remplacé DoSomething().

Answer 4

Rien à ajouter aux aspects sémantiques de "final".

Cependant, j'aimerais ajouter au commentaire de Chris Green que "final" pourrait devenir une technique d'optimisation du compilateur très importante dans un avenir proche. Non seulement dans le cas simple qu'il a mentionné, mais aussi pour des hiérarchies de classes du monde réel plus complexes qui peuvent être "closes" par "final", permettant ainsi aux compilateurs de générer un code de dispatching plus efficace que l'approche habituelle de vtable.

Un inconvénient clé des vtables est que, pour tout objet virtuel (en supposant 64 bits sur un CPU Intel typique), le pointeur seul occupe 25% (8 sur 64 octets) d'une ligne de cache. Dans le genre d'applications que j'aime écrire, cela fait très mal. (Et de mon expérience, c'est l'argument n ° 1 contre le C++ du point de vue de la pure performance, c'est-à-dire par les programmeurs en C.)

Dans les applications qui nécessitent des performances extrêmes, ce qui n'est pas si rare pour le C++, cela pourrait effectivement devenir impressionnant, ne nécessitant pas de contourner ce problème manuellement de style C ou d'acrobaties de modèles bizarres.

Cette technique est connue sous le nom de Désirtualisation. Un terme à retenir. :-)

Il y a un discours récent formidable d'Andrei Alexandrescu qui explique plutôt bien comment vous pouvez contourner de telles situations aujourd'hui et comment "final" pourrait faire partie de la résolution de problèmes similaires "automatiquement" à l'avenir (discuté avec les auditeurs) :

http://channel9.msdn.com/Events/GoingNative/2013/Writing-Quick-Code-in-Cpp-Quickly

Answer 5

Final ne peut pas être appliqué aux fonctions non virtuelles.

error: seules les fonctions membres virtuelles peuvent être marquées comme 'final'

Il ne serait pas très significatif de pouvoir marquer une méthode non virtuelle comme 'final'. Étant donné

struct A { void foo(); };
struct B : public A { void foo(); };
A * a = new B;
a -> foo(); // cela appellera de toute façon A :: foo, indépendamment de l'existence d'un B::foo

a->foo() appellera toujours A::foo.

Mais, si A::foo était virtual, alors B::foo le remplacerait. Cela pourrait être indésirable, il serait donc logique de rendre la fonction virtuelle finale.

La question est cependant, pourquoi autoriser final sur les fonctions virtuelles. Si vous avez une hiérarchie profonde:

struct A            { virtual void foo(); };
struct B : public A { virtual void foo(); };
struct C : public B { virtual void foo() final; };
struct D : public C { /* ne peut pas remplacer foo */ };

Alors le final met un 'plafond' sur le niveau de substitution possible. D'autres classes peuvent étendre A et B et remplacer leur foo, mais si une classe étend C, alors cela n'est pas autorisé.

Il ne semble donc probablement pas logique de rendre la fonction 'de niveau supérieur' final, mais cela pourrait avoir du sens plus bas dans la hiérarchie.

(Je pense cependant qu'il y a de la place pour étendre les mots final et override aux membres non virtuels. Ils auraient cepend differente signification.)