Yıkıcı neden iki kez idam edildi?

#include <iostream>
using namespace std;

class Car
{
public:
    ~Car()  { cout << "Car is destructed." << endl; }
};

class Taxi :public Car
{
public:
    ~Taxi() {cout << "Taxi is destructed." << endl; }
};

void test(Car c) {}

int main()
{
    Taxi taxi;
    test(taxi);
    return 0;
}

bu çıktı :

Car is destructed.
Car is destructed.
Taxi is destructed.
Car is destructed.

MS Visual Studio Community 2017 kullanıyorum (Maalesef, Visual C ++ sürümlerini nasıl göreceğimi bilmiyorum). Hata ayıklama modunu kullandığımda. void test(Car c){ }İşlev gövdesini beklendiği gibi terk ederken bir yıkıcı yürütülür . Ve bittiğinde ekstra bir yıkıcı ortaya çıktı test(taxi);.

test(Car c)İşlev resmi parametresi olarak kullanılır. Bir Araba işleve giderken kopyalanır. Bu yüzden işlevden ayrılırken sadece bir "Araba imha edilecek" diye düşündüm. Ama aslında fonksiyondan ayrılırken iki "Araba imha edilir" (çıkışta gösterildiği gibi birinci ve ikinci satır) Neden iki "Araba imha edilir"? Teşekkür ederim.

===============

class Car Örneğin bir sanal işlevi eklediğimde : virtual void drive() {} Beklenen çıktıyı alıyorum.

Car is destructed.
Taxi is destructed.
Car is destructed.

Visual Studio derleyicisi, taxiişlev çağrısı için dilimleme yaparken biraz kısayol alıyor gibi görünüyor , bu da ironik bir şekilde beklenenden daha fazla iş yapmasına neden oluyor.

İlk olarak, argümanınız eşleşecek şekilde taxibir kopyasını kendiniz alıyor ve Carondan bir kopya oluşturuyor .

Daha sonra, geçiş değeri için Car tekrar kopyalanıyor .

Bu davranış, kullanıcı tanımlı bir kopya oluşturucu eklediğinizde ortadan kalkar, bu nedenle derleyici bunu kendi nedenleriyle yapıyor olabilir (belki de dahili olarak, daha basit bir kod yoludur), kopyanın kendisi önemsizdir. Önemsiz bir yıkıcı kullanarak bu davranışı hala gözlemleyebilmeniz biraz sapmadır.

Bunun ne derece yasal olduğunu (özellikle C ++ 17'den beri) veya derleyicinin bu yaklaşımı neden alacağını bilmiyorum, ancak sezgisel olarak beklediğim çıktı olmadığını kabul ediyorum. Ne GCC ne de Clang bunu yapmazlar, ancak işleri aynı şekilde yapıyor olabilirler, ancak kopyayı elide tutma konusunda daha iyi olabilirler. Ben var hatta VS 2019 hala garanti elision değil harika olduğunu fark ettim.

Ne oluyor ?

Bir oluşturduğunuzda Taxi, bir Caralt nesne de oluşturursunuz . Taksi yok edildiğinde, her iki nesne de yok edilir. Aradığınızda by değerini test()geçersiniz Car. Böylece bir saniye Carkopya oluşturulur ve test()bırakıldığında imha edilir. Bu yüzden 3 yıkıcı için bir açıklamamız var: dizideki ilk ve ikisi.

Dördüncü yıkıcı (dizideki ikinci) beklenmedik ve diğer derleyicilerle çoğaltamadım.

Yalnızca argüman Cariçin kaynak olarak geçici olarak yaratılabilir Car. Doğrudan temin zaman olmaz beri Carargüman olarak değerini, onu dönüştürme şüpheli TaxiINTO Car. Bu beklenmedik bir durum, çünkü Carher birinde zaten bir alt nesne var Taxi. Bu nedenle derleyicinin geçici olarak gereksiz bir dönüşüm yaptığını ve bu sıcaklıktan kaçınabilecek kopya seçimini yapmadığını düşünüyorum.

Yorumlarda verilen açıklama:

Burada, dil avukatının iddialarımı doğrulaması standardına referansla açıklama:

• Burada bahsettiğim dönüşüm, yapıcı tarafından bir dönüşüm [class.conv.ctor], yani başka bir türün (burada Taksi) bir argümana dayanan bir sınıfın (burada Araba) bir nesnesinin oluşturulmasıdır.
• Bu dönüşüm daha sonra Cardeğerini döndürmek için geçici bir nesne kullanır . Derleyiciye, [class.copy.elision]/1.1geçici bir inşa etmek yerine, doğrudan parametreye döndürülecek değeri oluşturabileceğinden, bir kopya seçimine izin verilecektir .
• Eğer bu sıcaklık yan etkiler veriyorsa, bunun nedeni derleyicinin bu olası kopya seçimini kullanmamasıdır. Kopya seçimi zorunlu olmadığı için yanlış değil.

Analizin deneysel teyidi

Şimdi aynı derleyiciyi kullanarak vakanızı yeniden oluşturabilir ve neler olduğunu doğrulamak için bir deneme yapabilirim.

Yukarıdaki varsayımım, derleyicinin Car(const &Taxi)doğrudan Caralt nesnesinden kopya oluşturma yerine yapıcı dönüşümünü kullanarak bir alt parametre geçirme işlemini seçmesiydi Taxi.

Bu yüzden aramayı denedim test()ama açıkça Taxibir Car.

İlk denemem durumu iyileştirmeyi başaramadı. Derleyici hala yetersiz yapıcı dönüşümünü kullanıyordu:

test(static_cast<Car>(taxi));  // produces the same result with 4 destructor messages

İkinci denemem başarılı oldu. Dökümü de yapar, ancak derleyiciye bu aptalca geçici nesneyi oluşturmadan ve Caralt Taxinesnesini kullanmasını şiddetle önermek için işaretçi dökümünü kullanır :

test(*static_cast<Car*>(&taxi));  //  :-)

Ve sürpriz: beklendiği gibi çalışıyor, sadece 3 imha mesajı üretiyor :-)

Sonuç deneyi:

Son bir denemede, dönüşümle özel bir oluşturucu sağladım:

 class Car {
 ... 
     Car(const Taxi& t);  // not necessary but for experimental purpose
 }; 

ve uygulamak *this = *static_cast<Car*>(&taxi);. Aptalca geliyor, ancak bu aynı zamanda sadece 3 yıkıcı mesajı görüntüleyecek ve böylece gereksiz geçici nesneden kaçınacak kod üretir.

Bu, derleyicide bu davranışa neden olan bir hata olabileceğini düşünmeye yol açar. Bazı durumlarda temel sınıftan doğrudan kopya oluşturma olasılığı kaçırılmış olabilir.