Почему все объекты qt в динамической памяти?

[pastor]

Я же говорю .... "Перечитал книжки, погуглил". Можешь в двух словах объяснить в чем разница? например в чем разница между 2-мя программами

Очень плохо гуглил ))

Heap vs. Stack
The stack and the heap
Stack vs Heap Allocation

[f0x]

Повлияет - рухнет на деструкторе, т.к. parent считает что все child'ы в куче и будет звать delete (btw: чем плохой ответ?)

Тем что это абсолютная ложь и если препод не чайник может запросто глянуть исходники Qt и послать вас на пересдачу.

QObject в деструкторе лезет к родителю и удаляет себя из него.

Поэтому с точки зрения работоспособности - создание в куче или в стеке абслолютно идентичны.

[Igors]

Повлияет - рухнет на деструкторе, т.к. parent считает что все child'ы в куче и будет звать delete (btw: чем плохой ответ?)

Тем что это абсолютная ложь ...

Аккуратнее пожалуйста. Грубость никогда не убеждает да и форум не украшает. Давайте не горячиться а разберемся спокойно. Пример, который привел spirit действительно будет работать корректно.

Код:

Test::Test(QWidget *parent)
	: QDialog(parent)
{
	m_label.setParent(this);
	m_label.setText("hello");
}

Выполняется удаление Test. Сначала вызовется деструктор Test. Он позовет деструктор m_label, значит m_label будет удален из children'ов Test и второй раз m_label удаляться не будет. Все хорошо.

А теперь чуть-чуть усложним пример

Код:

#include <QtGui>
#include <qDebug>

class MyLabel : public QLabel {
public:
	MyLabel( QWidget * parent = 0 ) : QLabel(parent) {}

    virtual ~MyLabel( void )  
	{ 
		qDebug() << "destruct MyLabel"; 
	}	
};

class MyFrame : public QFrame {
public:
	MyFrame( QWidget * parent = 0 ) : QFrame(parent) {}

    virtual ~MyFrame( void )  
	{ 
		qDebug() << "destruct MyFrame"; 
	}	
};

class MyDialog : public QDialog {
public:
	MyDialog( QWidget * parent = 0 ) : QDialog(parent)
	{
		mFrame.setParent(this);
		mLabel.setParent(&mFrame);
	}

// data	
	MyLabel mLabel;
	MyFrame mFrame;
};

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

	MyDialog dlg;
	return 0;
}

А вот тут уже рассыпалось - деструктор mFrame вызывается первым и прется удалить mLabel. Конечно, если поменять местами члены mFrame и mLabel - все заработает. Но хотите ли Вы так программировать?

[BRE]

Пример, который привел BRE действительно будет работать корректно.

Какой пример, где приводил?   

[Igors]

Какой пример, где приводил?   

Ивините, описАлся и исправил, этот пример привел spirit

[f0x]

Аккуратнее пожалуйста. Грубость никогда не убеждает да и форум не украшает. Давайте не горячиться а разберемся спокойно.

Приношу извинения 

Конечно, если поменять местами члены mFrame и mLabel - все заработает. Но...

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

Код

C++ (Qt)
MyClass::MyMethod()
{
    Dialog * d = new Dialog()
...
...
   delete d;
}
 

?

[spirit]

имхо в таком случае лучше создать диалог в стеке и заюзать QDialog::exec.

[Igors]

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

Код

C++ (Qt)
MyClass::MyMethod()
{
    Dialog * d = new Dialog()
...
...
   delete d;
}
 

?

По-моему это дело вкуса. Я лично с удовольствием использую локальные объекты при первой возможности - люблю выскакивать из функций return'ом (хоть это и не по классике) и в этом случае деструктор сам все сделает, нечего беспокоиться о delete. "Расходы" (мол, больше памяти на стеке или "стек быстрее") здесь никто не учитывал даже на процессорах с частотой 9Mz, а сегодня уж и говорить нечего

[lit-uriy]

вообще троли давали объяснение почему они используют указатели. И объяснение достаточно развёрнутое.
Если вспомню где это было, дам ссылку.
В двух словах: безопаснее работать с указателями, т.к. применение некого API выглядит более интуитивным (маленький пример есть здесь)

[juvf]

Но хотите ли Вы так программировать? Улыбающийся

Конечно нет. Зачем так извращатся и создавать такие классы?  Igors, твой пример, ну очень уш извращенный. На практике такого не встречал. Зачем делать mLabel членом MyDialog, если его родителем будет не MyDialog? Мне кажется, что этот пример написан на тему "Я могу уронить программу без использования указателей". При желании можно любую программу уронить, и с указателями, и с локальными объектами. Возможно, в жизни где-то и необходим подобный код, но тогда нужно учесть особенности Qt. А вопрос, касательно использования членов-указателей вместо членов-объектов у тролей, остается открытым.

[Igors]

Но хотите ли Вы так программировать? Улыбающийся

Конечно нет. Зачем так извращатся и создавать такие классы?  Igors, твой пример, ну очень уш извращенный. На практике такого не встречал. Зачем делать mLabel членом MyDialog, если его родителем будет не MyDialog? Мне кажется, что этот пример написан на тему "Я могу уронить программу без использования указателей". При желании можно любую программу уронить, и с указателями, и с локальными объектами. Возможно, в жизни где-то и необходим подобный код, но тогда нужно учесть особенности Qt. А вопрос, касательно использования членов-указателей вместо членов-объектов у тролей, остается открытым.

Конечно, пример извращенный Но ведь я буквально следовал правилу: использовать члены-объекты вместо членов-указателей - и падает оно само, я его не ронял   А вот с использованием указателей надо еще постараться чтобы уронить. Делая объект членом класса, Вы тем самым заряжаете механизм его удаления в деструкторе. Это неизбежно будет заклинивать с Qt механизмом "parent удаляет своих children". Зачем же искать приключений на свою "голову" и доказывать что "можно и с членами-объектами написать"?

Конечно, из этого не следует что член-объект есть "плохо", например в классах для конкретных инженерных расчетов именно члены-объекты доминируют, незачем там указатели городить. Но в Qt UI (да и в любом UI) указатель гибче/лучше.

[SASA]

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

Попрошу не оскорблять. А лучше извиниться!
Я преподаю в универе и у меня есть работа за которую "платят не учительскую зарплату". Плюс ко всему я считаю себя неплохим программистом.
З.Ы. Извините за офтоп, но когда тебя называют бараном и недопрограммистом, это задевает.

[Vexator]

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

[SABROG]

З.Ы. Извините за офтоп, но когда тебя называют бараном и недопрограммистом, это задевает.

Поздравляю с Всемирным Днём Учителя!

[SASA]

Поздравляю с Всемирным Днём Учителя!

Спасибо.

З.Ы. Извините за офтоп, но когда тебя поздравляют, это приятно.