Czy wbudowane funkcje wirtualne są naprawdę pozbawione sensu?

Question

Mam to pytanie, gdy otrzymałem komentarz z komentarzem do kodu, mówiąc, że funkcje wirtualne nie muszą być wstawiane.

Pomyślałem, że wbudowane funkcje wirtualne mogą się przydać w scenariuszach, w których funkcje są wywoływane bezpośrednio na obiektach. Ale moim przeciw-argumentem stało się - dlaczego chciałoby się zdefiniować wirtualne, a następnie użyć obiektów do wywoływania metod?

Najlepiej nie używać wbudowanych funkcji wirtualnych, ponieważ i tak prawie nigdy nie są one rozwijane?

Fragment kodu użyłem do analizy:

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

Funkcje wirtualne można czasami wstawiać. Wyciąg z doskonałą C++ faq:

„Jedyny czas inline wirtualnego call można inlined jest, gdy kompilator wie«dokładnie klasy»obiektu który jest celem wirtualnego połączenia funkcji . może się to zdarzyć tylko gdy kompilator ma rzeczywistą obiektu zamiast wskaźnik lub odniesienie do przedmiot, tj. zarówno z lokalnego obiektu, obiekt globalny/statyczne albo całkowicie zamkniętego obiektu wewnątrz kompozytu . "

Answer 2

Kompilator może tylko funkcją inline, gdy połączenie może zostać rozwiązany w sposób jednoznaczny w czasie kompilacji.

Funkcje wirtualne są jednak rozwiązywane w środowisku wykonawczym, więc kompilator nie może wstawić wywołania, ponieważ podczas kompilacji typ dynamiczny (a zatem wywoływana funkcja) nie może zostać określony.

Answer 3

wbudowany naprawdę nic nie robi - to podpowiedź. Kompilator może to zignorować lub może zainicjować zdarzenie wywołania bez wbudowanego, jeśli widzi implementację i lubi ten pomysł. Jeśli wymagana jest klarowność kodu, należy usunąć wbudowany.

Answer 4

Dzięki nowoczesnym kompilatorom nie zaszkodzi im ich brak. Niektóre starsze kompilatory kompilatorów/łączników mogły utworzyć wiele tabel, ale nie sądzę, że to już jest problem.

Answer 5

W przypadkach, w których wywołanie funkcji jest jednoznaczne, a funkcja jest odpowiednim kandydatem do wstawiania, kompilator jest wystarczająco inteligentny, aby mimo wszystko wstawić kod.

Reszta czasu "inline virtual" jest nonsensem i rzeczywiście niektóre kompilatory nie skompilują tego kodu.

Answer 6

Istnieje jedna kategoria funkcji wirtualnych, w których nadal ma sens umieszczanie ich w linii. Rozważmy następujący przypadek:

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 
} 

Wezwanie do usunięcia „bazy”, wystąpi wirtualnego połączenia, aby połączyć poprawną pochodzący klasy destruktor, to połączenie nie jest inlined. Ponieważ jednak każdy destruktor nazywa go destruktem nadrzędnym (który w tych przypadkach jest pusty), kompilator może wywoływać wywołania, ponieważ nie wywołują one praktycznie żadnych funkcji klasy podstawowej.

Ta sama zasada istnieje dla konstruktorów klasy podstawowej lub dla dowolnego zestawu funkcji, w których pochodna implementacja wywołuje również implementację klas bazowych.

Answer 7

Widziałem kompilatory, które nie emitują żadnego v-table, jeśli nie istnieje żadna funkcja inline (i zdefiniowana w jednym pliku implementacji zamiast nagłówka). Rzucałyby błędy, takie jak missing vtable-for-class-A lub coś podobnego, i byłbyś zdezorientowany jak diabli, tak jak ja.

Rzeczywiście, nie jest to zgodne ze Standardem, ale tak się dzieje, więc należy rozważyć umieszczenie co najmniej jednej wirtualnej funkcji nie w nagłówku (jeśli jest to tylko wirtualny destruktor), aby kompilator mógł emitować tabelę vtable dla klasy w tym miejscu . Wiem, że dzieje się tak z niektórymi wersjami gcc.

Jak ktoś wspomniał, wbudowane funkcje wirtualne mogą być korzyści czasami, ale oczywiście najczęściej można go używać podczas wykonywania nie wiedzieć dynamiczny typ obiektu, bo to była cała przyczyna virtual na pierwszym miejscu.

Jednak kompilator nie może całkowicie zignorować inline. Ma inną semantykę oprócz przyspieszenia wywołania funkcji. domyślnie wbudowany dla definicji w klasie jest mechanizm, który pozwala umieścić definicję w nagłówku: Tylko funkcje inline można zdefiniować wiele razy w całym programie bez naruszania jakichkolwiek zasad. Ostatecznie zachowuje się tak, jak byś zdefiniował to tylko raz w całym programie, nawet jeśli wielokrotnie umieściłeś nagłówek w różnych połączonych ze sobą plikach.

Answer 8

Deklinowane funkcje wirtualne są wstawiane, gdy są wywoływane przez obiekty i ignorowane, gdy są wywoływane przez wskaźnik lub odwołania.

Answer 9

Właściwie funkcje wirtualne mogą zawsze być inlined, jak długo są one ze sobą powiązane statycznie: załóżmy, że mamy klasę abstrakcyjną Base z wirtualnym funkcji F i klas pochodnych Derived1 i Derived2:

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

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

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

Hipotetyczna rozmowa b->F(); (z b typu Base*) jest oczywiście wirtualna. Ale ty (lub compiler ...) mógłby przerobić go tak jak (załóżmy typeof jest typeid -jak funkcja, która zwraca wartość, która może być użyta w 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) 
} 

natomiast wciąż musimy RTTI dla typeof, połączenie może być skutecznie zainicjowane przez, w zasadzie, osadzenie tabeli vtable w strumieniu instrukcji i wyspecjalizowanie wywołania dla wszystkich zaangażowanych klas. Może to być także uogólnione przez specjalizującą się tylko kilka klas (powiedzmy tylko Derived1):

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

Answer 10

To ma sensu, aby funkcje wirtualne, a następnie połączyć je w obiektach, a nie referencje lub wskaźniki. Scott Meyer zaleca, w swojej książce "Skuteczne C++", aby nigdy nie redefiniować dziedziczonej funkcji nie-wirtualnej. Ma to sens, ponieważ gdy tworzysz klasę z funkcją inną niż wirtualna i na nowo definiujesz funkcję w klasie pochodnej, możesz być pewien, że użyjesz jej poprawnie, ale nie możesz być pewien, że inni będą jej używać poprawnie. Ponadto możesz później użyć go nieprawidłowo.Tak więc, jeśli tworzysz funkcję w klasie bazowej i chcesz, aby była możliwa do zmienienia, powinieneś uczynić ją wirtualną. Jeśli ma sens tworzenie funkcji wirtualnych i wywoływanie ich na obiektach, ma również sens wstawianie ich.

Answer 11

Oznaczanie wirtualna metoda inline, ułatwia dalszą optymalizację funkcji wirtualnej w dwóch następujących przypadkach:

• ciekawe powtarzające się szablon wzoru (http://www.codeproject.com/Tips/537606/Cplusplus-Prefer-Curiously-Recurring-Template-Patt)

• Wymiana metody wirtualne z szablonem (http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html)

Answer 12

C++ 11 dodał final. Zmienia to zaakceptowane odpowiedź: to już nie jest konieczne, aby poznać dokładną klasę obiektu, to wystarczy znać przedmiot ma co najmniej typ klasy, w których funkcja została zadeklarowana końcowa:

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