C++, виртуальный деструктор Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Переключить на: Стандартный Линейный

[Litkevich Yuriy]

Никак не могу въехать в виртуальный деструктор.
Есть некая программа написанная с использованием Qt, работает стабильно. При развитии программы, она может падать в некий момент времени, обычно при взаимодействии с пользовательским интерфейсом. Но чаще возникает авария при завершении работы.
Эту ситуацию можно пердотвратить в ведя в один из классов пустой, ничего не делающий, виртуальный деструктор.

Речь идёт о наследнике либо QObject, либо QWidget.

Может кто-нибудь объяснить, как может влиять создание руками виртуального деструктора, при условии, что его тело пустое?

[BRE]

Ситуация вообще странная.
Насколько я помню, виртуальный деструктор вводиться еще в QObject, т.е. все остальные деструкторы в наследниках (включая QWidget) по умолчанию виртуальные.

[Litkevich Yuriy]

Насколько я помню, виртуальный деструктор вводиться еще в QObject,

да, но вот Креатор, например, генерит файлы классов всегда с явно указанным деструктором, если базовый класс является QObject/QWidget.

Я просто решил сделать по аналогии, в одной из программ. которая падает при закрытии. И программа перестала падать.

Как это работает я не пойму.

Если я правильно понимаю, то должно работать так. Дано:

class QObject
{
              QObject();
  virtual ~QObject();
};


class MyObject : public QObject
{
              MyObject();

}

где-то далее в коде:

QObject  *o = new MyObject();
delete o; // <--------

в выделенной строке должен вызываться деструктор класса MyObject

или я не прав?

[BRE]

Прав.
Вызовется деструтор MyObject, а потом QObject.

[Litkevich Yuriy]

и ещё, при отладке в Креаторе увидел что в консоль приложения печатается такая строка:

Lowest section in J:\WINDOWS\system32\xpsp2res.dll is .rsrc at 00011000

если же запускаю программу в командной строке виндовоза, то такой надписи нет. Это может предвещать что-то плохое?

[Алексей1153]

Litkevich Yuriy, а когда запущено на отладку без точек останова - не видно, где падение произошло ? Обычно стек вызовов можно раскрутить до своего кода

[Litkevich Yuriy]

Обычно стек вызовов можно раскрутить до своего кода

да вот GDB сволочной отладчик, когда нужно найти проблему, он руками разводит, говорит "Может стек корупт, а?"


Но походу тут лажа очередная с qmake'ом. Прибил всю сборку, собрал начисто, всё работает. Даже намёка на падение нет, что без деструктора, что с явно созданным.

[DEADHUNT]

добавляя виртуальный деструктор получаем:
1) полиморфный класс, т.е. возможность использования dynamic_cast, typeid, ...
2) объекты можно удалять через указатель на базовый класс, при этом будет вызываться деструктор производного класса и корректно свобождается память.

[Влад]

Ежли мой склероз мне не изменяет, еще Джефф Элджер в своей "С++ Библиотека программиста" советовал: делайте деструктор всегда виртуальным, за исключением лишь тех случаев, когда есть чрезвычайно веские основания поступить иначе.

[Litkevich Yuriy]

добавляя виртуальный деструктор получаем:

речь идёт о деструкторе базового класса или наследника?

[DEADHUNT]

речь идёт о деструкторе базового класса или наследника?

class A {
    virtual ~A() { }
};

класс имеет виртуальный деструктор, т.е. в классе есть хотя бы один виртуальный метод, таким образом компилятор считает данный класс полиморфным, и обращается с ним иначе чем с обычными классами(как описано выше).

[Алексей1153]

за исключением лишь тех случаев, когда есть чрезвычайно веские основания поступить иначе

о, я даже прошёлся по этим граблям разок ) Если интересно, могу вспомнить

[Litkevich Yuriy]

класс имеет виртуальный деструктор

ну это-то понятно, это я в первых постах написал.
Мне не понятно, может ли влиять явное создание пустого деструктора у наследника QObject (или иного класса, с виртуальным деструктором).
На мой взгляд нет.


Но похоже это какая-то кривость Креатора. Любое изменение в коде (в заголовочниках) сейчас опять выливается в аврию. Если же компилю в консоли или в PN-2, то всё нормально.

[kwisp]

лишний повод(причина) не использовать креатор.

[Iron Bug]

Мне не понятно, может ли влиять явное создание пустого деструктора у наследника QObject (или иного класса, с виртуальным деструктором).
На мой взгляд нет.

однозначно нет.
скорее всего, ошибка в потоках, либо в оставшихся "висящими" объектах ядра. проверяй, все ли ресурсы освобождаются корректно, правильно ли завершаются потоки, нет ли "подвисших" линков на несуществующие переменные после закрытия основного потока.

[Алексей1153]

и ещё
... вызываются ли виртуальные функции в деструкторе (низя)
... производится ли где-то явное приведение типа с последующим изменением начала объекта (бьётся таблица виртуальных функций)

[BRE]

... вызываются ли виртуальные функции в деструкторе (низя)

Почему нельзя?

[kwisp]

BRE,
не знаю почему но могу предположить:
при вызове вирт. диструктора вызывается на самом деле деструктор производного объекта(уничтожает поля производного класса) , который в свою очередь вызывает деструктор базового класса(тот самый виртуальный) ав нем виртуальные функции которые могут использовать уже удаленные поля производного класса...

по моему логично

если диструктор не виртуальный а в нем виртуальные функции то эти вирту функции напросто обратятся уже к удаленным полям производного объекта.
порядок вызова деструкторов обратный то

[Алексей1153]

Вроде нельзя, потому что виртуальная таблица уже порушена. Будут вызываться функции данного объекта, а не потомков
А как там в стандарте ?

Надо будет эксперимент поставить, но щас у меня мысль в другом русле, пока не могу )

Сообщение отредактировал Алексей1153 - 17.8.2010, 19:13

[BRE]

На сколько я помню, при удалении объекта с виртуальным деструктором, будет вызван деструктор из его vtbl. После его отработки, vtbl будет переключена на таблицу базового класса и будет вызван его деструктор и т.д. Даже если ты будешь удалять объект по указателю на его базовый класс. В этом и смысл.
А вот с конструкторами такое не пройдет, они не могут быть виртуальными. Поэтому, в конструкторе будет вызван виртуальный метод того класса, конструктор которого в данный момент работает, даже если в производном классе он переопределен.

[Алексей1153]

нет, речь не про виртуальный деструктор, а про явный вызов виртуальных функций из деструктора предка

[BRE]

Ты про чисто виртуальные функции или просто виртуальные?

[Алексей1153]

Щас сделаю тест, самому охота вспомнить )

хм, выяснилась интересная вещь. Ни Креатор, ни Студия (№6, №9) просто не позволяют так сделать ещё на уровне линковки

class A
{
public:
    virtual void F()=0;

    void CallF()
    {
        F();
    }

    virtual ~A()
    {
        F();//<<<<< на это ругань
    }
};

class B:public A
{
public:
    void F()
    {
        int iii=1;
    }

    void CallF()
    {
        F();
    }

    ~B()
    {
        F();
    }
};


void main()
{
    B b;
    b.CallF();
}

unresolved external symbol "public: virtual void __thiscall A::F(void)" (?F@A@@UAEXXZ)

undefined reference to `A::F()'

А ведь я помню, нарвался как то на подобное, но не могу вспомнить, как именно

Сообщение отредактировал Алексей1153 - 17.8.2010, 19:54

[Iron Bug]

На сколько я помню, при удалении объекта с виртуальным деструктором, будет вызван деструктор из его vtbl. После его отработки, vtbl будет переключена на таблицу базового класса и будет вызван его деструктор и т.д. Даже если ты будешь удалять объект по указателю на его базовый класс. В этом и смысл.
А вот с конструкторами такое не пройдет, они не могут быть виртуальными. Поэтому, в конструкторе будет вызван виртуальный метод того класса, конструктор которого в данный момент работает, даже если в производном классе он переопределен.

абсолютно верно. именно так и будет.
если в классе виртуальная функция определена, то она может быть вызвана в деструкторе этого класса и в деструкторах классов-наследников, если вдруг потребуется. для каждого класса могут использоваться его функции и функции прародителей. для деструктора нет ограничений. они есть только для конструктора - так как в момент создания элемента виртуальной таблицы и указателя this просто ещё нет.

[Litkevich Yuriy]

... вызываются ли виртуальные функции в деструкторе (низя)

нет, у меня именно пустой деструктор (мне нечего было подчищать при завершении работы класса), а насчёт того, что нельзя, я тоже краем уха где-то слышал.

... производится ли где-то явное приведение типа с последующим изменением начала объекта

вот это не понял, что значит с изменением начала объекта?

[Алексей1153]

а насчёт того, что нельзя, я тоже краем уха где-то слышал.

поскольку точно не могу факт привести, не буду придумывать Лучше всегда поставить эксперимент на месте и проверить в отладчике.

вот это не понял, что значит с изменением начала объекта?

например

Раскрывающийся текст

    //общий вид сообщения из 4 байтов
    struct SomeMessage
    {
        //флаги, общие для всех сообщений
        BYTE b1:1;
        BYTE b2:1;
        BYTE b3:1;
        BYTE b4:1;
        BYTE b5:1;
        BYTE b6:1;
        BYTE b7:1;
        BYTE b8:1;

        //код сообщения
        BYTE m_Code;

        //разные данные - зависят от m_Code
        WORD m_SomeData;

        virtual ~SomeMessage()
        {
            m_Code=0;
        }

        void FillMe(DWORD dwdRawData)
        {
            //грабля №1 - размер *this равен 8 байтов, а не 4, как ожидается
            //поэтому проверка вернёт false
            if(sizeof(*this)==sizeof(dwdRawData))
            {
                //грабля №2 - запись произошлы бы не в тело структуры, а 
                //ровнёхонько в виртуальную таблицу
                *((DWORD*)this)=dwdRawData;
            }
        }
    };


void main()
{
    DWORD dwd=0x110022FF;
    SomeMessage m;
    m.FillMe(dwd);
    //виртуальная таблица была бы испорчена, если бы не проверка №1 в функции

}

Сообщение отредактировал Алексей1153 - 18.8.2010, 6:52

[kwisp]

хм, выяснилась интересная вещь. Ни Креатор, ни Студия (№6, №9) просто не позволяют так сделать ещё на уровне линковки

ты в первом посте верно написал - при вызове виртуальных функций из деструктора - просто напросто вызовутся функции того класса чей деструктор а не предков.
что стандарт по этому поводу говорит конечно интересно.
а не линкуется, потому что получается вызов чисто виртуальной функции.

Раскрывающийся текст

# include <iostream>
# include <string>

class Parent 
{
public:
    /*virtual*/ ~Parent()
    {
        std::cout << __PRETTY_FUNCTION__ << '\n';
        printData();
    }
    virtual void printData()
    {
        std::cout << __PRETTY_FUNCTION__ << '\n';
    }
};

class Child : public Parent
{
public:
    Child()
    {
        std::cout << __PRETTY_FUNCTION__ << '\n';
        m_data = new std::string("hello world");
    }
    void printData()
    {
        std::cout << __PRETTY_FUNCTION__ << '\n';
        std::cout << *m_data << '\n';
    }
    ~Child()
    {
        std::cout << __PRETTY_FUNCTION__ << '\n';
        delete m_data;
    }

private:
    std::string* m_data;

};

int main()
{
    Child* child = new Child;
    static_cast<Parent*>(child)->printData();
    delete child;
    return 0;
}

./a.out 
Child::Child()
virtual void Child::printData()
hello world
Child::~Child()
Parent::~Parent()
virtual void Parent::printData()

[Алексей1153]

функции данного объекта, а не потомков

kwisp, вообще-то, я про потомков говорил ) Ведь назначение виртуальных функций - вызывать методы потомков

вызов чисто виртуальной функции.

такой вызов не запрещён вроде
Потому что абстрактный объект создать нельзя, а потомки должны обязательно переопределить виртуалки

Сообщение отредактировал Алексей1153 - 18.8.2010, 10:13

[kwisp]

Будут вызываться функции данного объекта, а не потомков

вот

такой вызов не запрещён вроде

да ну не верится.

[Алексей1153]

что тут верить то Проверить, и всё

class A
{
public:
    virtual void F()=0;

    void Call_F()
    {
        F();
    }

    virtual ~A()
    {
    }

};

class B:public A
{
public:
    void F()
    {

    }
};

main()
{

    A* pa =new B;

    pa->F();
    pa->Call_F();
    delete pa;
    pa=0;
}

Сообщение отредактировал Алексей1153 - 18.8.2010, 12:22

[kwisp]

Алексей1153,
хитрец ты вызываешь не чисто виртуальную функцию а переорпеделенную.
рассмотри пример у меня в посте выше и вывод на консоль.

[DEADHUNT]

что тут верить то Проверить, и всё

код собирается без ошибок.
а в конце 10.4 (Abstract Classes) написано:

Member functions can be called from a constructor (or destructor) of an abstract class; the effect of making a
virtual call (10.3) to a pure virtual function directly or indirectly for the object being created (or destroyed)
from such a constructor (or destructor) is undefined.

в таких случаях лучше реализовывать чисто виртуальную функцию:

class A {
public:
    virtual void foo() = 0;
};

void A::foo()
{
}

[Алексей1153]

хитрец ты вызываешь не чисто виртуальную функцию а переорпеделенную.

прошагай отладчиком - никакой хитрости Или я просто не понял, что ты имел в виду под "вызов чистых виртуальных функций". Ведь в классе A - это и есть есть чистая

Сообщение отредактировал Алексей1153 - 18.8.2010, 13:58

[DEADHUNT]

Или я просто не понял, что ты имел в виду под "вызов чистых виртуальных функций".

struct A {
virtual void foo() = 0;
};

struct B : public A {

void foo()
{
    A::foo(); // <-
}

};

Сообщение отредактировал DEADHUNT - 18.8.2010, 14:03

[Iron Bug]

Может кто-нибудь объяснить, как может влиять создание руками виртуального деструктора, при условии, что его тело пустое?

я уже писала: никак не влияет. просто лишний вызов или перераспределение кода при очередной компиляции скрывает ошибку потоков или затирания памяти.
от пустого деструктора абсолютно ничего не прибавляется, виртуальный он или не виртуальный.

[Алексей1153]

DEADHUNT, понятно )

А я то понял, что про именно из A вызов говорилось

Сообщение отредактировал Алексей1153 - 18.8.2010, 19:13

[Litkevich Yuriy]

вобщем шутки RunTime продолжаются.

Похоже, что чуваки утверждавшие, что qmake - для простеньких приложений, правы. И видимо я дорос до более сложного приложения.

Прога падает при некоторых изменениях в исходнике. падает в самых неожиданных местах. Попытка добавить qDebug в выше стоящие по иерархии модули решает проблему (т.к. эти модули перекомпилируются).
Проделал такой эксперимент. При возникновении проблем, в один из вышестоящих модулей добавляю пустую строку - это вызывает перекомпиляцию. И теперь прога работает стабильно.

Не уж-то на CMake придётся переходить? Так не охота что-то изучать на середине проекта.

[Алексей1153]

Litkevich Yuriy, а у тебя нигде директива не используется такая?
#pragma pack


upd
(всё, вопрос неактуален )) Внимательнее прочитал пост Юрия и понял, что это ни при чём)

Сообщение отредактировал Алексей1153 - 19.8.2010, 12:44

[DEADHUNT]

Не уж-то на CMake придётся переходить? Так не охота что-то изучать на середине проекта.

а все вызовы дополнительных утилит(moc, uic, etc.) в ручную прописывать?

[BRE]

а все вызовы дополнительных утилит(moc, uic, etc.) в ручную прописывать?

Зачем? CMake это все умеет и даже намного больше.

[DEADHUNT]

вот нашёл пример: http://www.devexp.ru/2010/01/cmake-i-qt/ там макросы для этого есть.
на самом деле зачем постоянно использовать qmake, ведь проект который использует Qt != Qt проект.

[Litkevich Yuriy]

а все вызовы дополнительных утилит(moc, uic, etc.) в ручную прописывать?

можно и так сказать, т.к. отдельные списки создавать надо