Le funzioni virtuali in linea sono davvero un non senso?

Question

Ho questa domanda quando ho ricevuto un commento di revisione del codice che dice che le funzioni virtuali non devono essere in linea.

Ho pensato che le funzioni virtuali incorporate potrebbero rivelarsi utili in scenari in cui le funzioni vengono richiamate direttamente sugli oggetti. Ma la contro-argomentazione mi è venuta in mente: perché si vorrebbe definire virtuale e quindi usare gli oggetti per chiamare i metodi?

È meglio non utilizzare funzioni virtuali in linea, poiché non vengono quasi mai espanse?

Snippet di codice che ho usato per l'analisi:

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

Le funzioni virtuali possono essere talvolta allineate. Un estratto dalla eccellente C++ faq:

"L'unica volta una linea chiamata virtuale può essere inline è quando il compilatore conosce la 'classe esatta' dell'oggetto che è la destinazione della chiamata funzione virtuale . Ciò può avvenire solo quando il compilatore ha un oggetto effettivo anziché un puntatore o riferimento a un oggetto. Vale a dire, sia con un oggetto locale, un oggetto globale/statico, o un oggetto completamente contenuta all'interno di un composito ".

Answer 2

Un compilatore può solo inline una funzione quando la chiamata può essere risolto in modo inequivocabile al momento della compilazione.

Le funzioni virtuali, tuttavia, vengono risolte in fase di esecuzione e pertanto il compilatore non può in linea la chiamata, poiché in fase di compilazione non è possibile determinare il tipo dinamico (e quindi l'implementazione della funzione da chiamare).

Answer 3

in linea in realtà non fa nulla - è un suggerimento. Il compilatore potrebbe ignorarlo o potrebbe incorporare un evento di chiamata senza in linea se vede l'implementazione e gli piace questa idea. Se è in gioco la chiarezza del codice, è necessario rimuovere in linea.

Answer 4

Con i compilatori moderni, non farà alcun danno inli li. Alcune combo di compilatore/linker antiche potrebbero aver creato più vtables, ma non credo che questo sia più un problema.

Answer 5

Nei casi in cui la chiamata di funzione non è ambigua e la funzione è un candidato idoneo per l'inlining, il compilatore è abbastanza intelligente da inline comunque il codice.

Il resto del tempo "in linea virtuale" è un'assurdità, e in effetti alcuni compilatori non compilano tale codice.

Answer 6

C'è una categoria di funzioni virtuali in cui ha ancora senso averle in linea. Si consideri il seguente caso:

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 
} 

La chiamata a cancellare 'base', si esibirà una chiamata virtuale per chiamare corretta distruttore della classe derivata, questo invito non è inline. Tuttavia, poiché ogni distruttore chiama il suo distruttore principale (che in questi casi è vuoto), il compilatore può chiamare in linea quelle, poiché non chiamano virtualmente le funzioni della classe base.

Lo stesso principio esiste per costruttori della classe base o per qualsiasi insieme di funzioni in cui l'attuazione derivato richiede anche l'implementazione classi base.

Answer 7

ho visto compilatori che non emettono alcun v-tavolo se nessuna funzione non inline affatto esiste (e definiti in un unico file di implementazione, invece di un colpo di testa poi). Avrebbero buttato errori come missing vtable-for-class-A o qualcosa di simile, e saresti stato confuso da morire, come lo ero io.

In effetti, questo non è conforme allo Standard, ma accade in questo caso considera di mettere almeno una funzione virtuale non nell'intestazione (se solo il distruttore virtuale), in modo che il compilatore possa emettere un vtable per la classe in quel luogo . So che succede con alcune versioni di gcc.

Come qualcuno ha detto, in linea funzioni virtuali possono essere un vantaggio volte, ma naturalmente il più delle volte si intende utilizzare quando si fanno non conoscere il tipo dinamico dell'oggetto, perché quello era l'unica ragione per virtual innanzitutto.

Il compilatore tuttavia non può ignorare completamente inline. Ha altre semantiche oltre ad accelerare una chiamata di funzione. Il implicita in linea per le definizioni in-classe è il meccanismo che permette di mettere la definizione nell'intestazione: Solo inline funzioni possono essere definiti più volte durante tutto il programma senza una violazione delle regole. Alla fine, si comporta come lo avresti definito solo una volta nell'intero programma, anche se hai incluso l'intestazione più volte in file diversi collegati insieme.

Answer 8

inline dichiarato funzioni virtuali sono inline quando viene chiamato attraverso oggetti e ignorato quando viene chiamato tramite puntatore o riferimenti.

Answer 9

Beh, in realtà funzioni virtuali possono sempre essere inline, a patto che stanno staticamente collegati tra loro: supponiamo di avere una classe astratta Base con una funzione virtuale F e classi derivate Derived1 e Derived2:

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

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

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

Una chiamata ipotetico b->F(); (con b di tipo Base*) è ovviamente virtuale. Ma voi (o la compiler ...) potrebbe riscrivere in questo modo (supponiamo typeof è una funzione typeid -come che restituisce un valore che può essere utilizzato in un 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) 
} 

mentre abbiamo ancora bisogno per la RTTI typeof, la chiamata può essere effettivamente integrata, basicamente, incorporando il vtable all'interno del flusso di istruzioni e specializzando la chiamata per tutte le classi coinvolte. Questo potrebbe essere generalizzata anche specializzandosi solo poche classi (diciamo, solo Derived1):

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

Answer 10

ha senso per rendere le funzioni virtuali e poi li chiamano su oggetti piuttosto che riferimenti o puntatori. Scott Meyer raccomanda, nel suo libro "C++ efficace", di non ridefinire mai una funzione non virtuale ereditata. Questo ha senso, perché quando si crea una classe con una funzione non virtuale e si ridefinisce la funzione in una classe derivata, si può essere certi di usarla correttamente da soli, ma non si può essere sicuri che altri la usino correttamente. Inoltre, puoi in seguito usarlo erroneamente.Quindi, se crei una funzione in una classe base e vuoi che sia modificabile, dovresti renderla virtuale. Se ha senso creare funzioni virtuali e chiamarle sugli oggetti, ha anche senso indicizzarle.

Answer 11

Marcatura un metodo in linea virtuale, aiuta ad ottimizzare ulteriormente le funzioni virtuali nei due casi seguenti:

• motivo template Curiosamente ricorrente (http://www.codeproject.com/Tips/537606/Cplusplus-Prefer-Curiously-Recurring-Template-Patt)

• Sostituzione metodi virtuali con i modelli (http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html)

Answer 12

C++ 11 ha aggiunto final. Questo cambia la risposta accettata: non è più necessario conoscere la classe esatta dell'oggetto, è sufficiente conoscere l'oggetto ha almeno il tipo di classe in cui la funzione è stata dichiarata 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. 
}