Hi, On Fri, 13 Dec 2002, Brad Settlemyer wrote:
> No, that seems like a bad idea as const is used for compile time const > checking by the compiler, but when implemented as a class the ability to > substitute const instances is different I think. (e.g. const ness can > always be resolved at compile time, type cannot). I can't see any advantage > in implementing const in this fashion, this does not allow you to make const > guarantees in you postconditions. Which part are you referring to? If it was the original idea of having const methods that take a const node and return a const node (such as getNextSibling) then the advantage I see is that if (for example)you pass in a const DOMDocument to a method then you cannot change the document. This seems a lot nicer. If it is the second part then the advantages I see are: 1) you can create Level 2 iterator things when you have a const node 2) when you do create an iterator the methods that you call cannot change the the node being passed in and any methods you use to access other nodes also return a const node. This would prevent you from gaining access to a non-const version of the node (which *is* const) through dom method calls. For example, at present one might call TreeWalker.previousSibling().getNextSibling(), having the effect of a const cast. Have I misunderstood you or am I missing something? Gareth > > > > -----Original Message----- > > From: Gareth Reakes [mailto:[EMAIL PROTECTED]] > > Sent: Friday, December 13, 2002 8:32 AM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: RE: FW: Const-correctness in Xerces and TreeWalker > > > > > > 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] > > > > > > > --------------------------------------------------------------------- > 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]
