Yes, agreed. I think of this as a special case, though. Since QGraphicsScene contents are often dynamic, there needs to be special handling of item addition and removal. QWidget hierarchies are usually more static. But if you remove an item from a scene and that item itself has child items, when you delete the item, its children will automatically be deleted by the parent-child ownership protocol.Just to give you an example of needing to call delete on a Qt class instance - if you remove an item from a QGraphicsScene then you have ownership and will need to delete it manually.
This is interesting - I thought "top" would have been shown as being destroyed last. My understanding of C++ construction was that construction proceeded from most-derived up to base class, and destruction proceeded from base class downward to most-derived, so the body of the destructor for the most-derived class would be executed last. Thus I would have expected that the messages for destruction would show "c", then "a", "b", and finally "top".Constructed "top"
Constructed "a"
Constructed "b"
Constructed "c child of a"
Destroyed "top"
Destroyed "a"
Destroyed "c child of a"
Destroyed "b"
Obviously my understanding must be faulty, or is this behaviour an artifact of qDebug()?
Edit ---
Duh (after performing a head-whack) - no this is completely backward; construction goes up the hierarchy, with the body of the base class executed first, followed by each derived class, until finally the most-derived class's constructor gets executed. Destruction goes the other way. So the qDebug() statements as originally given do show things happening in the order they actually occur. My apologies for not having had enough coffee before starting to type.My understanding of C++ construction was that construction proceeded from most-derived up to base class, and destruction proceeded from base class downward to most-derived,




Reply With Quote
Bookmarks