Hi Mark, "Mark Weaver" <[EMAIL PROTECTED]> wrote: > > However, if I understand you code correctly, the following is the > > equivalent of what you were doing before: > > > > theNodeList->addNode(&(*it).second->rtree()); > > > Unfortunately rtree() returns a const pointer, and addNode takes a non-const > pointer.
I think this is one of the cases where you are justified in using a const_cast. The old code in getNodesetRoot() did that for the same reason you need to. The reason, if you're interested, is the history of Xalan-C and its origins in Java. One great thing I'd like to do in a 2.0 version is to make the interfaces const throughout, which would solve these inconsistencies. On the other hand, the DOM interfaces really don't talk about const, since the concept is language specific, so we'ed probably need to extend or re-write the XalanDOM classes, so maybe it's not such a good idea after all. You could also do something like getting the first child of the XalanDocumentFragment instance, then calling getParentNode(), which should yield the exact same pointer, only it will be a non-const copy of the pointer: const XalanDocumentFragment& rtree = (*it).second->rtree(); XalanNode* const firstChild = rtree.getFirstChild(); assert(firstChild != 0); XalanNode* const parent = firstChild->getParentNode(); assert(parent == &rtree); > > The node set doesn't own any of the nodes and won't clean them up > > when it's > > destroyed. > > > Presumably then, clone is wrong because the clone won't be cleaned up? In > that case, I'm kind of stuck! Cloning is not supported, nor is it needed. Copying entire result tree because our interfaces are not completely const correct is really inefficient. Hope that helps! Dave
