Hi all,
I came across a problem related to this and would like to know how
other people handle this/ what they think. We need to create a
DOMTreeWalker from a const node. Now we do
DOMDocument *doc = node->getOwnerDocument();
this is already weird as we get back a non const and could traverse the
tree to find the node which we would have as non const as well. The scheme
discussed in previous mails would fix this.
DOMTreeWalker *tw = doc->createTreeWalker(node, 0, 0, true);
Now we cant do this as node is const.
I cant see any way around this at all with the current code except for
the evil const cast. This seems unacceptable to me. Throughout a
significant portion of Pathan we deal with const nodes and we cannot use
the Level 2 iteration methods.
Proposed solution:
So, to take the scheme further we would have a createConstTreeWalker method
in document (as well as createConstNodeIterator) which returns a new class
ConstDOMTreeWalker in which all the members/methods are const and they
return const DOMNodes. This is a deviation from the spec but I believe a
required one for C++.
what do people think?
Gareth
>
> Hi all,
> anyone any opinions on this? It seems like a good idea to me.
>
>
> Gareth
>
>
> > Hi,
> >
> > Currently Xerces is only const-correct for the current object, not
> > the whole DOM.
> >
> > ie. you can do:
> >
> > const DOMNode* constNode = ...;
> > DOMNode* nonConstChild = constNode->getFirstChild();
> > DOMNode* nonConstNode = nonConstChild->getParentNode();
> >
> > which breaks the const correctness.
> >
> > It would be nice if the const-correctness was carried through to the
> > whole DOM. This would prevent the above (maybe accidental) code.
> >
> > To do that you'd need to change all of the navigation methods like
> > so:
> >
> > Take 'virtual DOMNode* getParentNode() const' and change it to
> > 'virtual DOMNode* getParentNode()', then add
> > 'virtual const DOMNode* getParentNode() const' which simply
> > does 'return const_cast<DOMNode*>(this)->getParentNode();'
> >
> > Alternatively you could get the non-const one to call the const
> > one, which would probably be better since then the compiler would be
> > able to check the constness of the internals of the function.
> >
> > In order to not have any performance overhead you could make the
> > 'const DOMNode* getParentNode() const' non-virtual and inline,
> > defined only in the base class. This prevents a derived class from
> > overriding it, but that may be a good thing - after all we need
> > to guarantee the const/non-const versions do the same thing!
> >
> > Any thoughts on this? The main disadvantage I can see with it is
> > it wouldn't be much fun to implement (although I dare say Perl could
> > find a use in here somewhere). Oh, also it might break some broken
> > code.
> >
> > Cheers,
> >
> > Martin.
> >
> > This message is for the named person's use only. It may contain sensitive
> and private proprietary or legally privileged information. No
> confidentiality or privilege is waived or lost by any mistransmission. If
> you are not the intended recipient, please immediately delete it and all
> copies of it from your system, destroy any hard copies of it and notify the
> sender. You must not, directly or indirectly, use, disclose, distribute,
> print, or copy any part of this message if you are not the intended
> recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE
> FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT
> SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications
> through its networks. Any views expressed in this message are those of the
> individual sender, except where the message states otherwise and the sender
> is authorized to state them to be the views of any such entity.
> > Unless otherwise stated, any pricing information given in this message is
> indicative only, is subject to change and does not constitute an offer to
> deal at any price quoted. Any reference to the terms of executed
> transactions should be treated as preliminary only and subject to our
> formal written confirmation.
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> --
> Gareth Reakes, Head of Product Development +44-1865-203192
> DecisionSoft Limited http://www.decisionsoft.com
> XML Development and Services
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Gareth Reakes, Head of Product Development +44-1865-203192
DecisionSoft Limited http://www.decisionsoft.com
XML Development and Services
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
