Qt-interest Archive, August 2006
Re: deletion of the objects qt3
Message 1 in thread
Till Oliver Knoll wrote:
>
> So deleting such dialogs is perfectly possible here (the other or
> preferred way would be allocating such dialogs on the stack, so they are
> automatically removed, but there might be a situation where this is not
> possible and you really want to allocate the dialog - or whatever other
> QObject based object - on the heap; see the Qt interest archive for an
> extensive discussion/matter of taste about "heap vs. stack" allocation -
> but be warned! ;)
>
Declaring QObjects on the stack is dangerous. The doc seems to imply
that declaring QObjects on the stack AND given parents, this will
eventually lead to a crash. So long as you don't give it a parent, then
this is ok.
From QObject destructor docs:
Warning: All child objects are deleted. If any of these objects are on
the stack or global, sooner or later your program will crash.
--
[ signature omitted ]
Message 2 in thread
On 01.08.06 09:38:31, Minh Tran wrote:
> Till Oliver Knoll wrote:
> >So deleting such dialogs is perfectly possible here (the other or preferred
> >way would be allocating such dialogs on the stack, so they are automatically
> >removed, but there might be a situation where this is not possible and you
> >really want to allocate the dialog - or whatever other QObject based object -
> >on the heap; see the Qt interest archive for an extensive discussion/matter of
> >taste about "heap vs. stack" allocation - but be warned! ;)
>
> Declaring QObjects on the stack is dangerous. The doc seems to imply that
> declaring QObjects on the stack AND given parents, this will eventually lead to
> a crash. So long as you don't give it a parent, then this is ok.
>
> From QObject destructor docs:
> Warning: All child objects are deleted. If any of these objects are on the
> stack or global, sooner or later your program will crash.
The thing you miss here is that when the parent is destructed, the
dialog that has been created on the stack is long gone and not a child
of the parent anymore.
Andreas
--
[ signature omitted ]
Message 3 in thread
Andreas Pakulat wrote:
>
>
> The thing you miss here is that when the parent is destructed, the
> dialog that has been created on the stack is long gone and not a child
> of the parent anymore.
>
You are probably correct here. Which makes me wonder, what is the
purpose of the warning on the docs?
--
[ signature omitted ]
Message 4 in thread
Minh Tran wrote:
> Andreas Pakulat wrote:
> > The thing you miss here is that when the parent is destructed, the
> > dialog that has been created on the stack is long gone and not a child
> > of the parent anymore.
>
> You are probably correct here. Which makes me wonder, what is the
> purpose of the warning on the docs?
Maybe to outlaw situations like
void foo()
{
QObject * parent = new QObject;
QObject child(parent);
delete parent;
// child is dead here.
}
Regards,
Andre'
--
[ signature omitted ]
Message 5 in thread
"Minh Tran" <mtran@xxxxxxxxxxxxxxxx> wrote in message
news:44CE9477.4060905@xxxxxxxxxxxxxxxxxxx
> Declaring QObjects on the stack is dangerous. The doc seems to imply
> that declaring QObjects on the stack AND given parents, this will
> eventually lead to a crash. So long as you don't give it a parent, then
> this is ok.
>
> From QObject destructor docs:
> Warning: All child objects are deleted. If any of these objects are on
> the stack or global, sooner or later your program will crash.
I think it's a question of scope. I imagine if the QObject
is a member it may be deleted in the dtor before or
after the parent does its cleanup. Not sure about
that though. But since QObjects aren't copyable or
assignable, it's not easy to make a QDialog static member
with a valid parent for example.
In limited scope, like creating a dialog in a function
and calling exec() on it, I don't see a problem. We
typically do this unless we need a member. Then we
usually make is a QPointer to guarantee that it's
nulled when destroyed. Seems to work well.
--
[ signature omitted ]
