Les fonctions virtuelles en ligne sont-elles vraiment un non-sens ?

Question

Cette question m'a été posée lorsque j'ai reçu un commentaire de révision de code disant que les fonctions virtuelles ne doivent pas être en ligne.

Je pensais que les fonctions virtuelles en ligne pourraient être utiles dans les scénarios où les fonctions sont appelées directement sur les objets. Mais le contre-argument qui m'est venu à l'esprit est le suivant : pourquoi voudrait-on définir des fonctions virtuelles et utiliser ensuite des objets pour appeler des méthodes ?

Est-il préférable de ne pas utiliser les fonctions virtuelles en ligne, puisqu'elles ne sont presque jamais développées de toute façon ?

Extrait de code que j'ai utilisé pour l'analyse :

class Temp
{
public:

    virtual ~Temp()
    {
    }
    virtual void myVirtualFunction() const
    {
        cout<<"Temp::myVirtualFunction"<<endl;
    }

};

class TempDerived : public Temp
{
public:

    void myVirtualFunction() const
    {
        cout<<"TempDerived::myVirtualFunction"<<endl;
    }

};

int main(void) 
{
    TempDerived aDerivedObj;
    //Compiler thinks it's safe to expand the virtual functions
    aDerivedObj.myVirtualFunction();

    //type of object Temp points to is always known;
    //does compiler still expand virtual functions?
    //I doubt compiler would be this much intelligent!
    Temp* pTemp = &aDerivedObj;
    pTemp->myVirtualFunction();

    return 0;
}

Answer 1

Les fonctions virtuelles peuvent parfois être inlined. Un extrait de l'excellent FAQ sur le C++ :

"La seule fois où un appel virtuel en ligne peut être inlined est quand le compilateur connaît la "classe exacte" de l'objet qui est la cible de l'appel de fonction fonction virtuelle. Cela ne peut se produire que lorsque le compilateur dispose d'un objet réel plutôt qu'un pointeur ou une référence à un objet. C'est-à-dire, soit avec un objet local un objet global/statique ou un objet entièrement objet entièrement contenu dans un composite".

Answer 2

C++11 a ajouté final . Cela change la réponse acceptée : il n'est plus nécessaire de connaître la classe exacte de l'objet, il suffit de savoir que l'objet a au moins le type de classe dans lequel la fonction a été déclarée finale :

class A { 
  virtual void foo();
};
class B : public A {
  inline virtual void foo() final { } 
};
class C : public B
{
};

void bar(B const& b) {
  A const& a = b; // Allowed, every B is an A.
  a.foo(); // Call to B::foo() can be inlined, even if b is actually a class C.
}

Answer 3

Il existe une catégorie de fonctions virtuelles pour lesquelles il est toujours utile de les avoir en ligne. Considérons le cas suivant :

class Base {
public:
  inline virtual ~Base () { }
};

class Derived1 : public Base {
  inline virtual ~Derived1 () { } // Implicitly calls Base::~Base ();
};

class Derived2 : public Derived1 {
  inline virtual ~Derived2 () { } // Implicitly calls Derived1::~Derived1 ();
};

void foo (Base * base) {
  delete base;             // Virtual call
}

L'appel à la suppression de 'base', effectuera un appel virtuel pour appeler le destructeur correct de la classe dérivée, cet appel n'est pas inlined. Cependant, étant donné que chaque destructeur appelle son destructeur parent (qui, dans ces cas, est vide), le compilateur peut inline ceux puisqu'ils n'appellent pas virtuellement les fonctions de la classe de base.

Le même principe existe pour les constructeurs des classes de base ou pour tout ensemble de fonctions où l'implémentation dérivée appelle également l'implémentation des classes de base.

Answer 4

J'ai vu des compilateurs qui n'émettent pas de v-table si aucune fonction non-inline n'existe (et définie dans un fichier d'implémentation au lieu d'un en-tête). Ils lançaient des erreurs comme missing vtable-for-class-A ou quelque chose de similaire, et vous seriez confus comme l'enfer, comme je l'étais.

En effet, ce n'est pas conforme à la norme, mais cela arrive donc pensez à mettre au moins une fonction virtuelle qui n'est pas dans l'en-tête (ne serait-ce que le destructeur virtuel), afin que le compilateur puisse émettre une vtable pour la classe à cet endroit. Je sais que cela se produit avec certaines versions de gcc .

Comme quelqu'un l'a mentionné, les fonctions virtuelles en ligne peuvent être un avantage. parfois mais bien sûr, le plus souvent, vous l'utiliserez lorsque vous le ferez. pas connaître le type dynamique de l'objet, car c'était la raison d'être de virtual en premier lieu.

Le compilateur ne peut cependant pas ignorer complètement inline . Il a d'autres sémantiques que celle d'accélérer l'appel d'une fonction. Le site implicite en ligne pour les définitions en classe est le mécanisme qui vous permet de mettre la définition dans l'en-tête : Seulement inline Les fonctions peuvent être définies plusieurs fois dans l'ensemble du programme sans violation des règles. Au final, elle se comporte comme si vous ne l'aviez définie qu'une seule fois dans tout le programme, même si vous avez inclus l'en-tête plusieurs fois dans différents fichiers liés entre eux.

Answer 5

Eh bien, en fait les fonctions virtuelles peuvent toujours être inlined tant qu'elles sont statiquement liées entre elles : supposons que nous ayons une classe abstraite Base avec une fonction virtuelle F et les classes dérivées Derived1 y Derived2 :

class Base {
  virtual void F() = 0;
};

class Derived1 : public Base {
  virtual void F();
};

class Derived2 : public Base {
  virtual void F();
};

Un appel hypothétique b->F(); (avec b de type Base* ) est évidemment virtuelle. Mais vous (ou le compilateur ...) pourrait le réécrire comme suit (supposons que typeof est un typeid -qui renvoie une valeur pouvant être utilisée dans une fonction de type switch )

switch (typeof(b)) {
  case Derived1: b->Derived1::F(); break; // static, inlineable call
  case Derived2: b->Derived2::F(); break; // static, inlineable call
  case Base:     assert(!"pure virtual function call!");
  default:       b->F(); break; // virtual call (dyn-loaded code)
}

alors que nous avons toujours besoin de RTTI pour le typeof l'appel peut effectivement être inlined, en intégrant la vtable dans le flux d'instructions et en spécialisant l'appel pour toutes les classes concernées. Ceci pourrait aussi être généralisé en spécialisant seulement quelques classes (disons, juste Derived1 ) :

switch (typeof(b)) {
  case Derived1: b->Derived1::F(); break; // hot path
  default:       b->F(); break; // default virtual call, cold path
}