Satır içi sanal işlevler gerçekten mantıklı değil mi?

Sanal işlevler satır içinde olması gerektiğini söyleyerek bir kod inceleme yorum aldığımda bu soruyu aldım.

Satır içi sanal işlevlerin, işlevlerin doğrudan nesneler üzerinde çağrıldığı senaryolarda kullanışlı olabileceğini düşündüm. Ama aklıma gelen karşı argüman - neden sanal tanımlamak ve sonra yöntemleri çağırmak için nesneleri kullanmak istesin ki?

Neredeyse hiç genişletilmedikleri için satır içi sanal işlevleri kullanmamak en iyisidir?

Analiz için kullandığım kod snippet'i:

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

Sanal işlevler bazen satır içine alınabilir. Mükemmel C ++ SSS'den bir alıntı :

"Satır içi sanal çağrının satır içine alınabileceği tek zaman, derleyicinin sanal işlev çağrısının hedefi olan nesnenin" tam sınıfını "bilmesi durumudur. Bu, yalnızca derleyicinin işaretçi yerine gerçek bir nesnesi olduğunda veya yani bir yerel nesne, bir genel / statik nesne ya da bir bileşik içinde tam olarak kaplanmış bir nesne ile. "

C ++ 11 eklendi final. Bu, kabul edilen cevabı değiştirir: artık nesnenin tam sınıfını bilmek gerekli değildir, nesnenin en azından işlevin son olarak bildirildiği sınıf türüne sahip olduğunu bilmek yeterlidir:

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

Satır içi olmalarının hala mantıklı olduğu bir sanal işlev kategorisi vardır. Aşağıdaki durumu düşünün:

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
}

'Base' silme çağrısı, doğru türetilmiş sınıf yıkıcıyı çağırmak için sanal bir çağrı gerçekleştirecektir, bu çağrı satır içi değildir. Bununla birlikte, her yıkıcı kendi üst yıkıcısını çağırdığı için (bu durumlarda boştur), derleyici bu çağrıları satır içine alabilir , çünkü temel sınıf işlevlerini sanal olarak çağırmazlar.

Aynı prensip, temel sınıf yapıcıları veya türetilmiş uygulamanın temel sınıflar uygulamasını da çağırdığı herhangi bir işlev kümesi için de geçerlidir.

Hiçbir satır içi işlevi yoksa (ve sonra bir başlık yerine bir uygulama dosyasında tanımlanmış) herhangi bir v-tablo yaymayan derleyiciler gördüm. Onlar gibi hatalar missing vtable-for-class-Aya da benzer şeyler fırlatacaklardı ve benim gibi cehennem gibi kafan karışacaktı.

Aslında, bu Standart ile uyumlu değildir, ancak bu durumda, en azından bir sanal işlevi başlıkta değil (yalnızca sanal yıkıcıysa) koymayı düşünün, böylece derleyici o yerdeki sınıf için bir vtable yayabilir. Bunun bazı sürümlerinde olduğunu biliyorumgcc .

Birisi de belirtildiği gibi, satır içi sanal fonksiyonlar bir yararı olabilir bazen ama ne zaman tabii en sık kullanırız değil nesnenin dinamik türünü biliyorum tüm sebebi buydu çünkü, virtualilk etapta.

Ancak derleyici tamamen görmezden gelemez inline. Bir işlev çağrısını hızlandırmanın dışında başka anlambilime sahiptir. Örtük inline sınıf tanımları için başlığın içine tanımını koymak sağlayan mekanizmadır: Sadece inlinefonksiyonları ihlali herhangi bir kural olmadan tüm program boyunca birden çok kez tanımlanabilir. Sonunda, başlığı birbirine bağlı farklı dosyalara birden çok kez eklemiş olsanız bile, programın tamamında yalnızca bir kez tanımlamış olduğunuz gibi davranır.

Aslında, sanal işlevler statik olarak birbirine bağlı oldukları sürece her zaman satır içine alınabilir : Base sanal bir işleve Fve türetilmiş sınıflara sahip soyut bir sınıfımız olduğunu varsayalım Derived1ve Derived2:

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

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

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

Hipotetik bir çağrı b->F();( btür ile Base*) açıkça sanaldır. Ama (veya derleyici ...) o kadar seviyorum yazabilirsiniz (varsayalım typeofbir olduğunu typeidbenzeri işlevi olduğunu döndürür bir de kullanılabilecek bir değer 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)
}

RTTI için hala ihtiyacımız olsa da typeof, çağrı etkili bir şekilde, vtable'ı talimat akışının içine gömerek ve çağrıyı tüm ilgili sınıflar için uzmanlaştırarak etkili bir şekilde sıralanabilir. Bu, sadece birkaç sınıfın uzmanlaştırılmasıyla da genelleştirilebilir (örneğin, sadece Derived1):

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

Sanal bir yöntemi satır içinde işaretlemek, aşağıdaki iki durumda sanal işlevleri daha da optimize etmeye yardımcı olur:

• Merakla yinelenen şablon deseni ( http://www.codeproject.com/Tips/537606/Cplusplus-Prefer-Curiously-Recurring-Template-Patt )

• Sanal yöntemleri şablonlarla değiştirmek ( http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html )

inline gerçekten hiçbir şey yapmaz - bu bir ipucu. Derleyici, bunu görmezden gelebilir veya uygulamayı görür ve bu fikri beğenirse, satır içi olmadan bir çağrı olayı satır içi yapabilir. Kod netliği söz konusu olduğunda satır içi çıkarılmalıdır.

Satır içi bildirilen Sanal işlevler, nesneler üzerinden çağrıldığında satır içi ve işaretçi veya referanslar ile çağrıldığında yok sayılır.

Modern derleyicilerle, onları inlabe etmek zarar vermez. Bazı eski derleyici / bağlayıcı kombinasyonları birden fazla vtable oluşturmuş olabilir, ancak artık bunun bir sorun olduğuna inanmıyorum.

Bir derleyici yalnızca çağrı derleme zamanında net bir şekilde çözülebildiğinde bir işlevi satır içine alabilir.

Bununla birlikte, sanal işlevler çalışma zamanında çözümlenir ve bu nedenle derleyici çağrıyı satır içine alamaz, çünkü derleme türünde dinamik tür (ve dolayısıyla çağrılacak işlev uygulaması) belirlenemez.

İşlev çağrısının açık olmadığı ve işlevin satır içine almak için uygun bir aday olduğu durumlarda, derleyici kodu yine de satır içine alacak kadar akıllıdır.

Geri kalan "satır içi sanal" saçmalıktır ve aslında bazı derleyiciler bu kodu derlemez.

Sanal işlevler yapmak ve sonra bunları referanslar veya işaretçiler yerine nesneler üzerinde çağırmak mantıklıdır. Scott Meyer, "etkili c ++" adlı kitabında, kalıtsal bir sanal olmayan işlevi asla yeniden tanımlamamayı önerir. Bu mantıklı değildir, çünkü sanal olmayan bir işleve sahip bir sınıf oluşturduğunuzda ve türetilmiş bir sınıfta işlevi yeniden tanımladığınızda, bunu kendiniz doğru kullandığınızdan emin olabilirsiniz, ancak başkalarının doğru şekilde kullanacağından emin olamazsınız. Ayrıca, daha sonraki bir tarihte yanlış yoruself kullanabilirsiniz. Bu nedenle, bir temel sınıfta bir işlev yaparsanız ve işlevin yeniden yapılandırılabilir olmasını istiyorsanız, onu sanal yapmalısınız. Sanal işlevler yapmak ve bunları nesneler üzerinde çağırmak mantıklıysa, bunları satır içi yapmak da mantıklıdır.

Aslında bazı durumlarda sanal bir son geçersiz kılma işlemine "satır içi" eklemek, kodunuzun derlenmemesini sağlayabilir, bu nedenle bazen bir fark olabilir (en azından VS2017s derleyicisi altında)!

Aslında VS2017'de derlemek ve bağlantı kurmak için c ++ 17 standardını ekleyerek sanal bir satır içi son geçersiz kılma işlevi yapıyordum ve iki projeyi kullanırken bir nedenden dolayı başarısız oldu.

Ben bir test projesi ve birim test olduğum bir uygulama DLL vardı. Test projesinde, gerekli diğer projedeki * .cpp dosyalarını içeren # "linker_includes.cpp" dosyası var. Biliyorum ... msbuild'i DLL'den nesne dosyalarını kullanacak şekilde ayarlayabileceğimi biliyorum, ancak cpp dosyalarını dahil etmekle ilgili bir microsoft'a özgü çözüm olduğunu ve sürümün çok daha kolay olduğunu unutmayın. xml dosyaları ve proje ayarları ve benzeri daha bir cpp dosyası ...

İlginç olan, test projesinden sürekli olarak linker hatası alıyordum. Kayıp fonksiyonların tanımını kopyala yapıştır ile eklemiş olsam da dahil et! Çok garip. Diğer proje inşa etti ve ikisi arasında bir proje referansı işaretlemek dışında bir bağlantı yok, bu yüzden her ikisinin de her zaman inşa edildiğinden emin olmak için bir inşa emri var ...

Ben derleyici bir tür hata olduğunu düşünüyorum. VS2020 ile birlikte gelen derleyicide olup olmadığına dair hiçbir fikrim yok, çünkü bazı SDK'ların yalnızca düzgün çalıştığı için eski bir sürüm kullanıyorum :-(

Sadece bunları satır içi olarak işaretlemenin bir şey ifade edebileceğini değil, hatta kodunuzun bazı nadir durumlarda oluşturulmamasını sağlayabileceğini de eklemek istedim! Bu garip ama bilmek güzel.

PS .: Üzerinde çalıştığım kod inlineing tercih bilgisayar grafikleri ile ilgili olduğunu ve bu yüzden hem final hem de satır içi kullandım. Ben serbest bırakma bile doğrudan ipucu olmadan bindirerek DLL oluşturmak için yeterince akıllı olduğunu umuyoruz son belirleyici tuttu ...

PS (Linux) .: Bu tür şeyleri rutin olarak yaptığım gibi gcc veya clang'da da aynı şeylerin olmasını beklemiyorum. Bu sorunun nereden geldiğinden emin değilim ... Linux'ta veya en azından biraz gcc ile c ++ yapmayı tercih ediyorum, ancak bazen proje ihtiyaçları farklı.