Just my 2 cents... Why not make the compiler worry about the overloading? Create 2 methods in DOMNode:
DOMDocument* DOMNode::getOwnerDocument(); const DOMDocument* DOMNode::getOwnerDocument() const; Which handles the getownerdoc problem. Then implement 2 methods in DOMDocument. DOMTreeWalker* DOMDocument::createTreeWalker(DOMNode* node, and so on...); const DOMTreeWalker* DOMDocument::createTreeWalker(const DOMNode* node, and so on...) const; Which handles the creation of non-const and const treewalkers. Or am I missing something obvious? /Erik -----Original Message----- From: Brad Settlemyer [mailto:[EMAIL PROTECTED]] Sent: den 13 december 2002 15:24 To: [EMAIL PROTECTED] Subject: RE: FW: Const-correctness in Xerces and TreeWalker 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. > -----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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
