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]

Reply via email to