Le funzioni virtuali inline sono davvero un non-senso?

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

Ho pensato che le funzioni virtuali inline possano tornare utili in scenari in cui le funzioni vengono chiamate direttamente sugli oggetti. Ma la controargomentazione mi è venuta in mente è: perché si dovrebbe definire virtuale e quindi usare oggetti per chiamare metodi?

È meglio non usare le funzioni virtuali inline, dato che non sono quasi mai espanse comunque?

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;
}

Le funzioni virtuali possono essere incorporate a volte. Un estratto dall'eccellente faq C ++ :

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

C ++ 11 è stato aggiunto final. Questo cambia la risposta accettata: non è più necessario conoscere la classe esatta dell'oggetto, è sufficiente sapere che 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.
}

Esiste una categoria di funzioni virtuali in cui ha ancora senso averle in linea. Considera il caso seguente:

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 per eliminare 'base', eseguirà una chiamata virtuale per chiamare il distruttore di classe derivato corretto, questa chiamata non è inline. Tuttavia, poiché ogni distruttore chiama il suo genitore distruttore (che in questi casi è vuoto), il compilatore può incorporare quelli chiamate, poiché non chiamano virtualmente le funzioni della classe base.

Lo stesso principio esiste per i costruttori di classi base o per qualsiasi set di funzioni in cui l'implementazione derivata chiama anche l'implementazione delle classi base.

Ho visto compilatori che non emettono alcuna v-table se non esiste alcuna funzione non inline (e definita in un file di implementazione anziché in un'intestazione). Avrebbero lanciato errori comemissing vtable-for-class-A o qualcosa di simile, e tu saresti confuso da morire, come me.

In effetti, questo non è conforme allo Standard, ma succede quindi considera di non inserire almeno una funzione virtuale nell'intestazione (se solo il distruttore virtuale), in modo che il compilatore possa emettere una tabella per la classe in quel posto. So che succede con alcune versioni digcc .

Come qualcuno ha detto, le funzioni virtuali inline possono essere un vantaggio a volte , ma ovviamente molto spesso lo userete quando non conoscete il tipo dinamico dell'oggetto, perché questa è stata la ragione principale virtualin primo luogo.

Il compilatore tuttavia non può ignorare completamente inline. Ha altra semantica oltre a velocizzare una chiamata di funzione. L' inline implicito per le definizioni in classe è il meccanismo che consente di inserire la definizione nell'intestazione: solo le inlinefunzioni possono essere definite più volte in tutto il programma senza violare alcuna regola. Alla fine, si comporta come l'avresti definito una sola volta nell'intero programma, anche se hai incluso più volte l'intestazione in file diversi collegati tra loro.

Bene, in realtà le funzioni virtuali possono sempre essere integrate , purché siano staticamente collegate tra loro: supponiamo di avere una classe astratta Base con una funzione virtuale Fe classi derivate Derived1e Derived2:

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

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

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

Una chiamata ipotetica b->F();(con btipo Base*) è ovviamente virtuale. Ma tu (o il compilatore ...) potresti riscriverlo in questo modo (supponiamo che typeofsia una typeidfunzione simile a quella che restituisce un valore che può essere usato in a 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 di RTTI per il typeof, la chiamata può essere efficacemente incorporata, fondamentalmente, incorporando la vtable all'interno del flusso di istruzioni e specializzando la chiamata per tutte le classi coinvolte. Questo potrebbe anche essere generalizzato specializzando solo alcune classi (diciamo, solo Derived1):

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

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

• Modello di modello curiosamente ricorrente ( http://www.codeproject.com/Tips/537606/Cplusplus-Prefer-Curiously-Recurring-Template-Patt )

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

inline non fa davvero nulla - è un suggerimento. Il compilatore potrebbe ignorarlo o potrebbe incorporare un evento call senza inline se vede l'implementazione e gradisce questa idea. Se è in gioco la chiarezza del codice, l' inline dovrebbe essere rimosso.

Le funzioni virtuali dichiarate incorporate vengono incorporate quando richiamate attraverso oggetti e ignorate quando richiamate tramite puntatore o riferimenti.

Con i compilatori moderni, non farà alcun male a loro. Alcune combo di compilatori / linker antichi potrebbero aver creato più vtables, ma non credo più che sia un problema.

Un compilatore può incorporare una funzione solo quando la chiamata può essere risolta in modo univoco al momento della compilazione.

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

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

Il resto del tempo "inline virtual" è un'assurdità, e in effetti alcuni compilatori non compileranno quel codice.

Ha senso creare funzioni virtuali e quindi chiamarle su oggetti anziché su riferimenti o puntatori. Scott Meyer raccomanda, nel suo libro "c ++ efficace", di non ridefinire mai una funzione non virtuale ereditata. Ciò 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 sicuri di utilizzarla correttamente da soli, ma non si può essere sicuri che altri la utilizzeranno correttamente. Inoltre, in un secondo momento è possibile utilizzarlo in modo errato. Quindi, se si crea una funzione in una classe base e si desidera che sia ridifinabile, è necessario renderla virtuale. Se ha senso creare funzioni virtuali e chiamarle su oggetti, ha anche senso incorporarle.

In realtà in alcuni casi l'aggiunta di "inline" a un override finale virtuale può impedire la compilazione del codice, quindi a volte c'è una differenza (almeno nel compilatore VS2017s)!

In realtà stavo facendo una funzione di override finale virtuale inline in VS2017 aggiungendo lo standard c ++ 17 per la compilazione e il collegamento e per qualche ragione non è riuscito quando sto usando due progetti.

Ho avuto un progetto di test e una DLL di implementazione che sto testando l'unità. Nel progetto di test sto avendo un file "linker_includes.cpp" che # include i file * .cpp dell'altro progetto necessari. Lo so ... So che posso configurare msbuild per usare i file oggetto dalla DLL, ma tieni presente che si tratta di una soluzione specifica per Microsoft, mentre includere i file cpp non è correlato al sistema di compilazione e molto più facile alla versione un file cpp rispetto ai file xml e alle impostazioni del progetto e simili ...

La cosa interessante è che stavo ricevendo costantemente errori del linker dal progetto di test. Anche se ho aggiunto la definizione delle funzioni mancanti con copia incolla e non tramite include! Così strano. L'altro progetto è stato creato e non esiste alcuna connessione tra i due oltre a contrassegnare un riferimento al progetto, quindi esiste un ordine di costruzione per garantire che entrambi siano sempre creati ...

Penso che sia una specie di bug nel compilatore. Non ho idea se esiste nel compilatore fornito con VS2020, perché sto usando una versione precedente perché alcuni SDK funzionano correttamente solo con quello :-(

Volevo solo aggiungere che non solo contrassegnarli come in linea può significare qualcosa, ma potrebbe anche rendere il tuo codice non compilato in alcune rare circostanze! Questo è strano, ma buono a sapersi.

PS .: Il codice su cui sto lavorando è legato alla grafica del computer, quindi preferisco inline ed è per questo che ho usato sia final che inline. Ho mantenuto l'identificatore finale sperando che la build di rilascio sia abbastanza intelligente da creare la DLL incorporandola anche senza di me suggerendo direttamente quindi ...

PS (Linux) .: Mi aspetto che lo stesso non accada in gcc o clang, come facevo abitualmente per fare questo tipo di cose. Non sono sicuro da dove provenga questo problema ... Preferisco fare c ++ su Linux o almeno con qualche gcc, ma a volte il progetto ha esigenze diverse.