QDomNode delete children

[zaphod.b]

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?

[trallallero]

I've removed the isElement and added a clear() but it doesn't help.

QDomNodeList nodeList = node.childNodes();
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);

QDomNodeList nodeList = node.childNodes();
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);

To copy to clipboard, switch view to plain text mode 

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.

[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.

[trallallero]

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.

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.

[zaphod.b]

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[*]:

void QDomNode::clear()
{
    if (impl && !impl->ref.deref())
        delete impl;
    impl = 0;
}

void QDomNode::clear()
{
    if (impl && !impl->ref.deref())
        delete impl;
    impl = 0;
}

To copy to clipboard, switch view to plain text mode 

The dtor indeed iterates the children, thus traversing the tree[*]:

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;
}

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;
}

To copy to clipboard, switch view to plain text mode 

[*] 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.