[Qt-interest] why parent widget in constructor?

[Andreas Pakulat]

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.

> because having the variables going out of scope causes button descrutor called 
> first by container one's and then by itself out of scope. Right?

Wrong. Both objects won't ever go out of scope, unless you explicitly
delete them via the delete operator (because via new you created them on
the heap). And then, Qt QObject's are intelligent enough to handle their
object tree, so if container is deleted first, it'll delete all its
children with it. On the other hand, if button is deleted first, then
it'll remove itself from its parent and when container later on is
deleted there's no child to delete.

> 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.
 
> However, another question that comes into my mind is why having the 
> setParent() method instead of an add one. I mean, why it is the child widget 
> that must specify which is its container, instead of having a container saying 
> which widget is one of its? This is more an OOP question, and after all the 
> child widget must notify the parent to add itself to its child list (or 
> whatever structure). So should not an add method be more clear?

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.

Andreas

-- 
Never give an inch!