Re: QDomNode delete children
From the QDomDocument doc:
Quote:
The parsed XML is represented internally by a tree of objects that can be accessed using the various QDom classes. All QDom classes only reference objects in the internal tree. The internal objects in the DOM tree will get deleted once the last QDom object referencing them and the QDomDocument itself are deleted.
If your document is too large for DOM, go with SAX.
Re: QDomNode delete children
I know but I just need to apply a patch as switching to SAX would take too much time now.
Re: QDomNode delete children
I suppose "cells" are child nodes of "row" in your DOM? removeChild() is not recursive, you'd have to to this yourself, or else "cells" remain referenced.
Re: QDomNode delete children
Good point thanks, but I tried this:
Code:
if (node.isElement())
{
for( int i = 0; i < nodeList.count(); ++i )
if( nodeList.at(i).isElement() )
nodeList.at(i).parentNode().removeChild(nodeList.at(i));
}
node.parentNode().removeChild(node);
and it doesn't work.
Node is the row and nodeList will contain all the "cells".
I've debugged it and removeChild is actually called.
If I delete each cell immediately after having created it (but it's something I cannot do), the used RAM goes up to 200MB, if I, instead, delete each row and all its children (the cells), the used RAM goes up to 900MB.
Something is removed because if I don't call any removeChild method, the used RAM goes up to 1.8GB and the program crashes.
Re: QDomNode delete children
Are your rows and cells represented by element nodes only?
If so, why do you still ask for isElement()?
If not, why do you only remove the element nodes?
What about attributes and text?
Re: QDomNode delete children
I've removed the isElement and added a clear() but it doesn't help.
Code:
for( int i = 0; i < nodeList.count(); ++i )
{
nodeList.at(i).clear();
nodeList.at(i).parentNode().removeChild(nodeList.at(i));
}
node.clear();
node.parentNode().removeChild(node);
clear() should remove all the attributes, no ?
Anyway, we decided to switch to QXmlStreamWriter/QXmlStreamReader but it would be interesting to understand why this happens. I've also asked Qt/Digia customer support but still no answer.
Re: QDomNode delete children
clear() won't delete the node itself, just make null node of it.
The code snippet you provided will now remove immediate child nodes, "cell elements" that is. I'd guess in general these cell elements will have child nodes themselves, e.g. text. As I wrote before, you'd have to make sure you traverse all descendant nodes, no matter what sublevel or type.
Re: QDomNode delete children
Quote:
Originally Posted by
zaphod.b
clear() won't delete the node itself, just make null node of it.
The code snippet you provided will now remove immediate child nodes, "cell elements" that is. I'd guess in general these cell elements will have child nodes themselves, e.g. text. As I wrote before, you'd have to make sure you traverse all descendant nodes, no matter what sublevel or type.
It's exactly the other way round as explained by the Qt support via email, received today.
Quote:
When you call removeChild() then all it is going to do is remove it from the current tree, you still get a reference to the QDomNode that you have removed which is why it still exists in memory because it hasn't been actually deleted. If you want to ensure that the contents of the node are also deleted then you need to call clear() on that node. This will cause it to be deleted and point to a null node and therefore the memory should be freed up for you. See:
http://qt-project.org/doc/qt-4.8/qdomnode.html#clear
But I will answer them tomorrow because this is not true.
If I only call clear(), nothing is deleted. The call to clear() seems to have no consequences.
Or, probably, for clear() it's as you said about removeChild(), call it recursively.
Re: QDomNode delete children
Sorry for the confusion. I remembered incorrectly from the distant past.
Meanwhile I had a look at the sources (5.1 but shouldn't have changed).
As you'll have seen from your debugging, clear() simply calls the impl dtor[*]:
Code:
{
if (impl && !impl->ref.deref())
delete impl;
impl = 0;
}
The dtor indeed iterates the children, thus traversing the tree[*]:
Code:
QDomNodePrivate::~QDomNodePrivate()
{
QDomNodePrivate* p = first;
QDomNodePrivate* n;
while (p) {
n = p->next;
if (!p->ref.deref())
delete p;
else
p->setNoParent();
p = n;
}
first = 0;
last = 0;
}
[*] I'm not sure what exactly deref() does, but if I interpret the asm correctly, it simply decrements the ref count and returns false if there are no references left, true otherwise. In the latter case deletion traversal terminates, and the node's subtree will dangle in the sense that it remains owned by the doc but is child of this node no more.
My conclusion is, if not all of your "row" is deleted, there must be reference(s) to its descendant(s). This is in accordance with the doc cited in post #2.
If you provided relevant parts of your code there might be a chance to locate the culprit.