[Qt-interest] why parent widget in constructor?

[Luca Ferrari]

On Monday 27 April 2009 13:09:28 Andreas Pakulat's cat walking on the keyboard 
wrote:
> On 27.04.09 12:52:50, Luca Ferrari wrote:
> > On Sunday 26 April 2009 14:12:44 Donal O'Connor's cat walking on the
> > keyboard
> >
> > wrote:
> > > Java has garbage collection, but in C++ something must take
> > > responsibility for deleting objects.
> >
> > It seems to me that this is more like a coding convention: having
> > destructor called from the last allocated variable to the first one,
> > causes that a parent initialized after a child widget will cause a double
> > call to the destructor of the child. So the following code in Java:
> >
> > JButton button = new JButton();
> > JPanel container = new JPanel();
> > container.add( button );
> >
> > must be translated into:
> >
> > QWidget* container = new QWidget();
> > QPushButton* button = new QPUshButton( container);
> >
> > or even in the manual case:
> >
> > QWidget* container = new QWidget();
> > QPushButton* button = new QPUshButton( );
> > button->setParent( container );
> >
> > but never to:
> >
> > QPushButton* button = new QPUshButton( );
> > QWidget* container = new QWidget();
> > button->setParent( container );
>
> There's no difference between these two creations.
>

Yes, sorry, I was thinking to stack allocation and not heap allocation. 
For heap allocation there is no difference at all, why of course variable can 
get out of scope when talking about stack allocation.



> > So, if the above is right there is not a real technological motivation
> > behind having a parent pointer in the widget constructor, rather it is a
> > mind-effort to keep memory safe. Please correct me if I'm wrong.
>
> The point in parent/child relationships is two-fold:
>
> a) a object hierarchy, that manages itself. If I delete an object in the
> hierarchy the whole subtree is deleted, without me needing to do
> anything. This is very nice for temporary windows/dialogs, I can create
> the window on the stack and even if all its children are created on the
> heap, they'll be deleted for me once the window goes out of scope.
>
> b) the parent/child relationship determines how widgets are layered in
> z-order.
>

Of course, but there is no need to build z-order from top to bottom or vice 
versa.

> Well, usually you don't set a parent on the child widget explicitly.
> setParent is for rare cases where you move widgets or objects around
> yourself. The usual way is to add widgets to a layout, which will set a
> proper parent behind the scenes.
>
> I agree though that if you want to add larger sets of objects to a
> parent they haven't been created for then an add method would be useful.

As you pointed out, working with layouts is different. In particular you have 
to add (thru and add method) a widget to a layout, and it is not clear (to me) 
why I should add a widget to a layout instead of simply setting the layout of 
a parent widget and keep adding the components to the parent widget. I also 
remind that in the qt 2 (maybe) you had to add a widget to the layout and 
express its z-order (so placing the widget double).

Luca