Russian Qt Forum

C++ (Qt)
MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{        
    ui->setupUi(this);
 
     root = new QObject(this);
 
    treeview = new TreeView(this);
    treemodel = new TreeModelBrowser(root);
    treeview->setModel(treemodel);
 
}
 

Скажите в данной ситуации treeview является  дочкой MainWindow или treemodel?

Если имеется ввиду всё-таки модель, то документация:


Если view, то непонятно почему возник такой вопрос - это первые уроки по Qt. Объект является ребёнком того объекта, который был передан как родитель в конструкторе. Т.е. MainWindow.

Согласен
Но когда я закрываю главное окно MainWidow в дебаг не выводится "Delete TreeView"

C++ (Qt)
void TreeView::actWscan()
{
            wps = new widgetScan()            
            wps->show();  
}
 
 
TreeView::~TreeView()
{
    qDebug()<<"Delete TreeView";
 
    if(wscan != NULL)
    {
        wscan->close();
        wscan = NULL;
    }
}
 

C++ (Qt)
widgetScan::widgetScan(QWidget *parent):
    QWidget(parent)
{
    setAttribute(Qt::WA_DeleteOnClose);
}
 

А ты удаление объекта явно вызови и увидишь.

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

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

В твоем варианте wps = new widgetScan() не является потомком TreeView, а значит его нужно удалять. Поэтому в событии close() нужно вызвать деструктор TreeView.

Если написать  wps = new widgetScan(this),  то будет удаляться и без деструктора по цепочке от дальнего предка к родителю.

Это бред, странно что приходится обсуждать вызов деструктора тут  :o

Абсолютно неверно! При удалении обекта всегда вызывается его деструктор (экстремальные случаи рассматривать не будем  ;) ). То есть стековые переменные при выходе из области видимости автоматически разрушаются с вызовом деструктора, а переменные в куче разрушаются с вызовом деструктора при удалении оператором delete.

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

Правы Вы только в одном - обычно при разрушении объектов их память не обнуляется.

Простите за некорректную формулировку на русском, я информатику на немецком изучаю. Вообще, под явным вызовом деструктора я подразумевал применение оператора delete. "Умные указатели" я, честно говоря, слабо понимаю, потому что на лекциях их затронули очень поверхностно. (Но речь то надо толкнуть, чтобы проверить что другие скажут :D )

Там и понимать-то нечего.  :) Если рассматривать самый простой "умный указатель", то это некий объект с конструктором и деструктором, который содержит ссылку на некие общие данные. Общие данные состоят из обычного указателя на нужный нам объект и счётчика ссылок. При создании копии умного указателя счётчик ссылок увеличивается, при разрушении - уменьшается. Последний разрушаемый умный указатель разрушает объект, указатель на который он хранит. Вот и всё.

C++ (Qt)
#include "mainwindow.h"
#include "ui_mainwindow.h"
 
MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);
    newWidow = NULL;
    connect(ui->pushButton,SIGNAL(clicked()),this,SLOT(addNewWindow()));
 
    setAttribute(Qt::WA_DeleteOnClose);
}
 
MainWindow::~MainWindow()
{
    delete ui;
 
    if(newWidow != NULL)
    {
        newWidow->close();
        delete newWidow;
        newWidow = NULL;
    }
}
 
void MainWindow::addNewWindow()
{
    if(newWidow == NULL)
    {
        newWidow = new MyWidget;
        connect(newWidow,SIGNAL(closeMyWidget()),this,SLOT(nullNewWindow()));
        newWidow->show();
    }
}
 
void MainWindow::nullNewWindow()
{
    newWidow = NULL;
}
 
 

C++ (Qt)
MyWidget::MyWidget(QWidget *parent):
    QWidget(parent)
{
    setAttribute(Qt::WA_DeleteOnClose);
}
 
MyWidget::~MyWidget()
{
    Q_EMIT closeMyWidget();
}
 

Не могу понять почему код работает с ошибкой ???
Пожалуйста подскажите :)

delete newWidow; — убери, оно и так само удаляется

убрал ,но
в debug пишет

demaker, если у тебя функция main выглядит так:

C++ (Qt)
Qapplication app;
MainWindow w;
w.show();
return app.exec();

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

Для тестов можешь попробовать это (http://www.forum.crossplatform.ru/index.php?showtopic=9735&view=findpost&p=65870)

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

P.S. вместо NULL пиши 0.

Спасибо, но не помогло

И что мне с этим делать ???

через вывод в консоль можно локализовать место, где падает :)

C++ (Qt)
qDebug() << 1;
foo * a;
qDebug() << 2;
a->doIt();
qDebug() << 3;
 
консоль:
1
2
Программа неожиданно завершилась бла-бла-бла...
 

Значит, ошибка между 2 и 3 :)

ты ведь нам свою функцию main не показал. если ты там создаешь mainwindow на стеке, то при закрытии главного окна программа пытается удалить память второй раз (атрибут удаления в mainwindow). удали этот атрибут и ошибка пропадет.

Слушай, kambala, вопрос к теме, но немного в сторону.
*(Кстати спасибо за объяснение "умных указателей" - стало чуть понятней)
Был у нас такой предмет на втором семестре - Теоретическая информатика, из которой очень хорошо можно было понять как резервируется физическая память, как ALU работает с регистрами и прочее. Но !!! Вот на программировании, что I что II никто не удосужился объяснить какие процессы происходят в памяти программ с точки зрения высоких языков (С/СPP). Подскажи литературу к этому вопросу. Спасибо!

не совсем понял вопрос. какой код напишешь — то и будет происходить. высокоуровневый код же преобразовывается в низкоуровневый (инструкции процессора). тебя интересует как команды С/С++ превращаются в ассемблерный код?

Почти. Просто, так же как и у автора поста порой возникают серьезные проблемы с пониманием того, как обращаться с памятью.
Например: создаю я указатель на диалоговое окно, которое посылает сигнал. После того как сигнал обработан я удаляю его оператором delete. Всегда спрашиваю себя, что там происходит в памяти? Как быть уверенным, что память полностью очистилась. А close() идентичен опературу delete или нет?

Или как в случае приведенном выше


Надеюсь сумел донести смысл того, что мне не понятно.

Хочется иметь в голове стройное представление как и что там в памяти происходит. Особенно  с указателями.

о таких тонкостях как-то никогда не задумывался :) как я это понимаю: область «кучи», на которую указывает указатель, помечается удаленной и становится невалидной. далее ОС уже решает что делать с этим куском памяти (изъять ее у программы или нет). может кто-то поправит/дополнит мой ответ.

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

стек же — это фиксированная область памяти (уже выделенная), в которой переменные просто занимают место (не нужно у ОС явно запрашивать память как в случае с кучей). попал на стек — ты уже с памятью, вылетел со стека — и ты «без памяти» (удаление происходит автоматически), т.е. переменная находится в невалидной области памяти. послеэ этого обратиться к переменной не даст компилятор (она будет вне области видимости), но при попытке удалить такую переменную delete'ом, она будет еще раз удалена при вылете со стека, что и приведет к падению программы.
нет конечно. но если ты окну поставишь атрибут WA_DeleteOnClose, то оно заодно и удалится.

Вот, спасибо, теперь понятно стало. А то я все путал. Для меня и steck и куча были одним и тем же! Прояснилось!

stack ;)

ТС да прочитайте про ассемблер книги под Вашу конкретную платформу... практически любой сишный или плюсовый компилятор умеет выдавать листинг ассемблера

Спасибо ,kambala, за разъяснения :)