| Trolltech Home | QSA-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
Hi Troll Tech & fellow QSA users,
I've discovered something in QSA that I'm not sure is exactly a bug, per se, but rather it appears to be a design decision that I think might be incorrect. Although, perhaps I am misunderstanding something.
As I've understood QSA, the "new" operator is used to declare an instance of an object. Conversely, there is no "delete" operator, but instead, all references to the object must be lost. For example:
var i = new Label; // Constructs a Label
i = 0; // Deletes it
In my case, I have defined some widgets that may be constructed through the QSObjectFactory, and in the script, you may specify their parent widget. For example:
var dialog = new VBox(0); // Parent == 0 means top-level
var label = new Label(dialog); // Child of dialog
I noticed here that if I now lose the reference to "label", it does not actually get deleted. However, if "label" had been constructed with no parent, (0 instead of dialog), it does get deleted when the reference is lost.
After some investigation, I tracked this behavior down to QSWrapperShared::invalidateWrapper() in quickobjects.cpp, specifically this part:
if( objects.count() > 0
&& objTyp == FactoryObject
&& objects.at(0)
&& !objects.at( 0 )->parent() ) {
delete objects[ 0 ];
}
Note the check here for the parent object. Apparently, QSA does not delete the underlying QObject if it is a child of some other object. This seems incorrect to me -- In my example above, I would expect the Label to be deleted when its reference is lost, even though it is a child of the VBox. Otherwise, as far as I can tell, there is simply no way to delete the object without first deleting its parent. I commented out the check for !objects.at(0)->parent() and it now behaves as I expect. Would you agree that this is the correct behavior? Am I missing something?
PS: I am looking forward to meeting you all at the Qt Developer Days conference in San Jose!
Joel Nordell
Software Engineer
ONEAC Corp.
Joel Nordell wrote: > Note the check here for the parent object. Apparently, QSA does not > delete the underlying QObject if it is a child of some other object. > This seems incorrect to me -- In my example above, I would expect the > Label to be deleted when its reference is lost, even though it is a > child of the VBox. Otherwise, as far as I can tell, there is simply no > way to delete the object without first deleting its parent. I commented > out the check for !objects.at(0)->parent() and it now behaves as I > expect. Would you agree that this is the correct behavior? Am I > missing something? The reason for this check is that there are scenarios where you'd want your objects to stick around after the script ends, for instance you populate a menubar with actions. On the otherhand we didn't want factory objects to leak so we had to device some mechanism for this to fit. We ended up with that most objects that stick around are because they fit into some greater scheme (the parent) and most shortlived are likely to be orhpans. If you need to delete your objects even when they are in a parent tree you could give them a delete slot that removes them from the parent and makes it possible for QSA to clean them, alternativly call the function reparent(). Its being considered that we add some controlling interface for this in the next version so that object lifetime can be better controlled from the users perspective. - Gunnar