You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Ebourne, Martin" <ma...@csfb.com> on 2002/12/04 14:37:36 UTC
FW: Const-correctness in Xerces
Gareth,
Tried sending this on Friday & again on Monday. Not seen it appear though.
Martin.
-----Original Message-----
From: Ebourne, Martin
Sent: 02 December 2002 14:37
To: 'xerces-c-dev@xml.apache.org'
Subject: Const-correctness in Xerces
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: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: question... again
Posted by Erik Rydgren <er...@mandarinen.se>.
Well make it....
<!xml version="foobar" encoding="foobar" standalone="yes"!>
<!doctype [
<!ELEMENT errors (error*)>
<!ELEMENT error EMPTY>
<!ATTLIST error
no ID #REQUIRED
and the other stuff
>
]>
<errors>
<error no="_12345" .... />
</errors>
.... then dammit :)
(And read with validation ON. Btw, watch out for nasty syntax errors. They
hunt in large numbers....)
/ Erik
-----Original Message-----
From: David N Bertoni/Cambridge/IBM [mailto:david_n_bertoni@us.ibm.com]
Sent: den 9 december 2002 17:28
To: xerces-c-dev@xml.apache.org
Subject: RE: question... again
Two problems here:
1. IDs are XML names, so they cannot be numbers. They must start with
either a letter or underscore:
http://www.w3.org/TR/REC-xml#NT-Name
2. You must declare the attribute as type ID in a DTD. Otherwise, the
parser will not consider them IDs, and they won't be available from
getElementById().
http://www.w3.org/TR/DOM-Level-2-Core/core.html#i-Document
Dave
"Erik Rydgren"
<erik.rydgren@man To:
<xe...@xml.apache.org>
darinen.se> cc: (bcc: David N
Bertoni/Cambridge/IBM)
Subject: RE: question...
again
12/09/2002 06:58
AM
Please respond to
xerces-c-dev
Well I would do it like this.
Add an ID attribute to all you error message description nodes with the
value of the error message.
Example:
<error id="12345" text_english="Some error text" text_foo="Error text in
foo language"/>
Parse the error description document with DOM and save the document for
error lookups.
On the document do a GetElementByID() methodcall supplying the error
number.
The method returns the element with the matching id attribute. Do a
GetAttribute("text_english") on the returned element to get the error
description in english.
Just note that the id attributes MUST be unique. But that is no problem for
you because error numbers tend to be unique by default :)
Regards
Erik Rydgren
Mandarinen systems AB
Sweden
-----Original Message-----
From: Sarah Leitner [mailto:leitners@spawar.navy.mil]
Sent: den 9 december 2002 15:24
To: xerces-c-dev@xml.apache.org
Subject: question... again
for some reason I couldn't get this question to deliver to the email list
Friday. So here it is. Hopefully it'll go through this time.
I've got lots of sample code for processing an entire XML document, but
none
for extracting one or two pieces of data from the document. In our case,
all
of our error messages will be in a separate document. I will then need to
use Xerces to match the error message to the error code that the system
generated. How in the world do I do something like this?
Sarah
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: question... again
Posted by David N Bertoni/Cambridge/IBM <da...@us.ibm.com>.
Two problems here:
1. IDs are XML names, so they cannot be numbers. They must start with
either a letter or underscore:
http://www.w3.org/TR/REC-xml#NT-Name
2. You must declare the attribute as type ID in a DTD. Otherwise, the
parser will not consider them IDs, and they won't be available from
getElementById().
http://www.w3.org/TR/DOM-Level-2-Core/core.html#i-Document
Dave
"Erik Rydgren"
<erik.rydgren@man To: <xe...@xml.apache.org>
darinen.se> cc: (bcc: David N Bertoni/Cambridge/IBM)
Subject: RE: question... again
12/09/2002 06:58
AM
Please respond to
xerces-c-dev
Well I would do it like this.
Add an ID attribute to all you error message description nodes with the
value of the error message.
Example:
<error id="12345" text_english="Some error text" text_foo="Error text in
foo language"/>
Parse the error description document with DOM and save the document for
error lookups.
On the document do a GetElementByID() methodcall supplying the error
number.
The method returns the element with the matching id attribute. Do a
GetAttribute("text_english") on the returned element to get the error
description in english.
Just note that the id attributes MUST be unique. But that is no problem for
you because error numbers tend to be unique by default :)
Regards
Erik Rydgren
Mandarinen systems AB
Sweden
-----Original Message-----
From: Sarah Leitner [mailto:leitners@spawar.navy.mil]
Sent: den 9 december 2002 15:24
To: xerces-c-dev@xml.apache.org
Subject: question... again
for some reason I couldn't get this question to deliver to the email list
Friday. So here it is. Hopefully it'll go through this time.
I've got lots of sample code for processing an entire XML document, but
none
for extracting one or two pieces of data from the document. In our case,
all
of our error messages will be in a separate document. I will then need to
use Xerces to match the error message to the error code that the system
generated. How in the world do I do something like this?
Sarah
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: question... again
Posted by Erik Rydgren <er...@mandarinen.se>.
Well I would do it like this.
Add an ID attribute to all you error message description nodes with the
value of the error message.
Example:
<error id="12345" text_english="Some error text" text_foo="Error text in
foo language"/>
Parse the error description document with DOM and save the document for
error lookups.
On the document do a GetElementByID() methodcall supplying the error number.
The method returns the element with the matching id attribute. Do a
GetAttribute("text_english") on the returned element to get the error
description in english.
Just note that the id attributes MUST be unique. But that is no problem for
you because error numbers tend to be unique by default :)
Regards
Erik Rydgren
Mandarinen systems AB
Sweden
-----Original Message-----
From: Sarah Leitner [mailto:leitners@spawar.navy.mil]
Sent: den 9 december 2002 15:24
To: xerces-c-dev@xml.apache.org
Subject: question... again
for some reason I couldn't get this question to deliver to the email list
Friday. So here it is. Hopefully it'll go through this time.
I've got lots of sample code for processing an entire XML document, but none
for extracting one or two pieces of data from the document. In our case, all
of our error messages will be in a separate document. I will then need to
use Xerces to match the error message to the error code that the system
generated. How in the world do I do something like this?
Sarah
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
question... again
Posted by Sarah Leitner <le...@spawar.navy.mil>.
for some reason I couldn't get this question to deliver to the email list
Friday. So here it is. Hopefully it'll go through this time.
I've got lots of sample code for processing an entire XML document, but none
for extracting one or two pieces of data from the document. In our case, all
of our error messages will be in a separate document. I will then need to
use Xerces to match the error message to the error code that the system
generated. How in the world do I do something like this?
Sarah
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: FW: Const-correctness in Xerces and TreeWalker
Posted by Gareth Reakes <ga...@decisionsoft.com>.
Hi,
I think it must have been me who has been unclear :). I am not
asking the type to enforce its own constness. If you want a const iterator
then you ask for one from the Document. This returns a completely
different class with const methods that return const DOMNodes and it has
(in the case of DOMTreeWalker) a private member root who's type is const
DOMNode *.
Does that make sense?
Gareth
> Yes, I think I must have been unclear. My only point was that a class
> cannot enforce constness via its own type (in your example
> ConstDomTreeWalker), because the enforcement mechanisms are different. Your
> way requires runtime type resolution at best, and even then can be
> circumvented without casting, whereas the only way to circumvent the const
> keyword is via a compile-time cast.
>
> I do agree that fixing the const correctness would be a good thing, I just
> don't think the way you proposed will work, Erik Rydgren however provided a
> solution which I do think is workable.
>
> Brad
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
--
Gareth Reakes, Head of Product Development +44-1865-203192
DecisionSoft Limited http://www.decisionsoft.com
XML Development and Services
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: FW: Const-correctness in Xerces and TreeWalker
Posted by Brad Settlemyer <bw...@strongholdtech.com>.
> 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.
>
[snip]
>
> Have I misunderstood you or am I missing something?
>
>
Yes, I think I must have been unclear. My only point was that a class
cannot enforce constness via its own type (in your example
ConstDomTreeWalker), because the enforcement mechanisms are different. Your
way requires runtime type resolution at best, and even then can be
circumvented without casting, whereas the only way to circumvent the const
keyword is via a compile-time cast.
I do agree that fixing the const correctness would be a good thing, I just
don't think the way you proposed will work, Erik Rydgren however provided a
solution which I do think is workable.
Brad
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: FW: Const-correctness in Xerces and TreeWalker
Posted by Gareth Reakes <ga...@decisionsoft.com>.
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:gareth@decisionsoft.com]
> > Sent: Friday, December 13, 2002 8:32 AM
> > To: xerces-c-dev@xml.apache.org; erik.rydgren@mandarinen.se
> > 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: xerces-c-dev-unsubscribe@xml.apache.org
> > > > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> > > >
> > > >
> > >
> > > --
> > > Gareth Reakes, Head of Product Development +44-1865-203192
> > > DecisionSoft Limited http://www.decisionsoft.com
> > > XML Development and Services
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> > >
> > >
> >
> > --
> > Gareth Reakes, Head of Product Development +44-1865-203192
> > DecisionSoft Limited http://www.decisionsoft.com
> > XML Development and Services
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
--
Gareth Reakes, Head of Product Development +44-1865-203192
DecisionSoft Limited http://www.decisionsoft.com
XML Development and Services
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: FW: Const-correctness in Xerces and TreeWalker
Posted by Ingolf Steinbach <in...@jena-optronik.de>.
* Erik Rydgren <er...@mandarinen.se> [2002-12-13 17:07]:
> The performance hit comes from larger vtables that needs to be set at object
> creation. After that...
And I think there should not even be a larger vtable. Ideally,
to avoid inconsistencies between the const and non-const variants,
the implementation could be:
class X;
class Base {
public:
virtual X const* foo() const;
inline X* foo();
private:
X* myX_;
};
inline X* BaseClass::foo()
{
BaseClass const& self(*this);
// We know that const_cast is ok here since "this" is a pointer
// to non-const
return const_cast<X*>(self.foo());
}
class Derived {
public:
// override only the const variant
virtual X const* foo() const;
// ...
};
Unfortunately, this would break a lot of code when the virtual foo()
is the non-const variant at the moment. So maybe the other way would
have to be taken (leave the non-const foo() virtual and provide a
const inline function in the base class). However, this approach is
IMHO not as secure as the variant above...
--
Ingolf Steinbach Jena-Optronik GmbH
ingolf.steinbach@jena-optronik.de ++49 3641 200-147
PGP: 0x7B3B5661 213C 828E 0C92 16B5 05D0 4D5B A324 EC04
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: FW: Const-correctness in Xerces and TreeWalker
Posted by Ingolf Steinbach <in...@jena-optronik.de>.
* Tinny Ng <tn...@ca.ibm.com> [2002-12-13 16:35]:
> I think we need to think again about this, as it's not only
> "createTreeWalker", the DOM document has all those createXXXX methods like
> "createElement", "createAtttribute" ..., and then all those inherited
> DOMNode interface like "removeChild", "replaceChild" ...etc.
[...]
Tinny,
I don't think that a pair of member functions would have to
be created for each operation. For example, there might be
member functions which indeed modify the DOM document (e.g.
the create/remove functions are good candidates). For these,
it is not necessary to create a "const" variant. For others,
(e.g. the tree walker), it's good to have both the const
and the non-const variant so that you can have a constant
DOM document and walk through it using only const member
functions.
IMHO, the decision when to have
1) only a non-const variant
2) only a const variant
3) both variants
of member functions would have to be done on a case-by-case
basis (depending on if the member function might change the
document *logically* - i.e. the object changes visibly to
the caller).
You might be interested in the recent thread titled "is const
correctness a dogma" in comp.lang.c++.moderated.
Regards
Ingolf
--
Ingolf Steinbach Jena-Optronik GmbH
ingolf.steinbach@jena-optronik.de ++49 3641 200-147
PGP: 0x7B3B5661 213C 828E 0C92 16B5 05D0 4D5B A324 EC04
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: FW: Const-correctness in Xerces and TreeWalker
Posted by Brad Settlemyer <bw...@strongholdtech.com>.
No, performance would be the same at worst and possibly be improved by
overloading on const-ness. Const is evaluated solely at compile time --
even const casts are only evaluated at compile time.
Const functions can theoretically be much faster than their non const
bretheren as the compiler knows more information at compile time, but either
way I'm uncertain of exactly where xerces spends its time during parse, so
I'm uncertain of how much improvement you would really see.
Brad
> -----Original Message-----
> From: Tinny Ng [mailto:tng-xml@ca.ibm.com]
> Sent: Friday, December 13, 2002 10:34 AM
> To: xerces-c-dev@xml.apache.org
> Subject: Re: FW: Const-correctness in Xerces and TreeWalker
>
>
> I think we need to think again about this, as it's not only
> "createTreeWalker", the DOM document has all those createXXXX methods like
> "createElement", "createAtttribute" ..., and then all those inherited
> DOMNode interface like "removeChild", "replaceChild" ...etc. If
> we have to
> overload each and every method with const modifier, it's not only
> a tedious
> work but also PERFORMANCE may impact badly with all these
> overloaded virtual
> functions. From my point of view, it just doesn't worth at all.
> Performance is much more important. I would prefer leave it as is.
>
> Tinny
>
> ----- Original Message -----
> From: "Ingolf Steinbach" <in...@jena-optronik.de>
> To: <xe...@xml.apache.org>
> Sent: Friday, December 13, 2002 10:00 AM
> Subject: Re: FW: Const-correctness in Xerces and TreeWalker
>
>
> > * Jennifer Schachter <ja...@decisionsoft.com> [2002-12-13 15:55]:
> > > This wouldn't help our problem: You cannot overload based on return
> > > type...
> > [...]
> > > On Fri, 13 Dec 2002, Erik Rydgren wrote:
> > [...]
> > > > DOMDocument* DOMNode::getOwnerDocument();
> > > > const DOMDocument* DOMNode::getOwnerDocument() const;
> > [...]
> > > > DOMTreeWalker* DOMDocument::createTreeWalker(DOMNode* node, and so
> on...);
> > > > const DOMTreeWalker* DOMDocument::createTreeWalker(const DOMNode*
> node, and
> > > > so on...) const;
> >
> > Note the "const" at the end of the lines. That's not overloading
> > on return type (additionally, the second createTreeWalker() takes
> > a "const DOMNode*"). So definitively the functions have a different
> > signature which makes overloading possible.
> >
> > Regards
> > Ingolf
> > --
> >
> > Ingolf Steinbach Jena-Optronik GmbH
> > ingolf.steinbach@jena-optronik.de ++49 3641 200-147
> > PGP: 0x7B3B5661 213C 828E 0C92 16B5 05D0 4D5B A324 EC04
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: FW: Const-correctness in Xerces and TreeWalker
Posted by Erik Rydgren <er...@mandarinen.se>.
After closer thought...
The vtable is created at compiletime and is shared between every instance of
a class.
Hence the only performance difference between 10 or 10000 virtual methods is
only the below mentioned
cache miss.
/ Erik
-----Original Message-----
From: Erik Rydgren [mailto:erik.rydgren@mandarinen.se]
Sent: den 13 december 2002 17:12
To: xerces-c-dev@xml.apache.org
Subject: RE: FW: Const-correctness in Xerces and TreeWalker
Yepp it is a tedius work. But I disagree that you will have to duplicate ALL
functions.
Either the method does not change the object: getAttribute, getTagname.
(implies const methods)
or it does change the object: insert, delete, setAttribute and so on
(non-const method)
However functions that returns objects need to have both a non-const as well
as an const variant.
The performance hit comes from larger vtables that needs to be set at object
creation. After that...
Well jumping 40 bytes into the vtable is not slower then jumping 20 bytes
into it ( unless you get a cache miss that is :) )
/ Erik
-----Original Message-----
From: Tinny Ng [mailto:tng-xml@ca.ibm.com]
Sent: den 13 december 2002 16:34
To: xerces-c-dev@xml.apache.org
Subject: Re: FW: Const-correctness in Xerces and TreeWalker
I think we need to think again about this, as it's not only
"createTreeWalker", the DOM document has all those createXXXX methods like
"createElement", "createAtttribute" ..., and then all those inherited
DOMNode interface like "removeChild", "replaceChild" ...etc. If we have to
overload each and every method with const modifier, it's not only a tedious
work but also PERFORMANCE may impact badly with all these overloaded virtual
functions. From my point of view, it just doesn't worth at all.
Performance is much more important. I would prefer leave it as is.
Tinny
----- Original Message -----
From: "Ingolf Steinbach" <in...@jena-optronik.de>
To: <xe...@xml.apache.org>
Sent: Friday, December 13, 2002 10:00 AM
Subject: Re: FW: Const-correctness in Xerces and TreeWalker
> * Jennifer Schachter <ja...@decisionsoft.com> [2002-12-13 15:55]:
> > This wouldn't help our problem: You cannot overload based on return
> > type...
> [...]
> > On Fri, 13 Dec 2002, Erik Rydgren wrote:
> [...]
> > > DOMDocument* DOMNode::getOwnerDocument();
> > > const DOMDocument* DOMNode::getOwnerDocument() const;
> [...]
> > > DOMTreeWalker* DOMDocument::createTreeWalker(DOMNode* node, and so
on...);
> > > const DOMTreeWalker* DOMDocument::createTreeWalker(const DOMNode*
node, and
> > > so on...) const;
>
> Note the "const" at the end of the lines. That's not overloading
> on return type (additionally, the second createTreeWalker() takes
> a "const DOMNode*"). So definitively the functions have a different
> signature which makes overloading possible.
>
> Regards
> Ingolf
> --
>
> Ingolf Steinbach Jena-Optronik GmbH
> ingolf.steinbach@jena-optronik.de ++49 3641 200-147
> PGP: 0x7B3B5661 213C 828E 0C92 16B5 05D0 4D5B A324 EC04
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: FW: Const-correctness in Xerces and TreeWalker
Posted by Erik Rydgren <er...@mandarinen.se>.
Yepp it is a tedius work. But I disagree that you will have to duplicate ALL
functions.
Either the method does not change the object: getAttribute, getTagname.
(implies const methods)
or it does change the object: insert, delete, setAttribute and so on
(non-const method)
However functions that returns objects need to have both a non-const as well
as an const variant.
The performance hit comes from larger vtables that needs to be set at object
creation. After that...
Well jumping 40 bytes into the vtable is not slower then jumping 20 bytes
into it ( unless you get a cache miss that is :) )
/ Erik
-----Original Message-----
From: Tinny Ng [mailto:tng-xml@ca.ibm.com]
Sent: den 13 december 2002 16:34
To: xerces-c-dev@xml.apache.org
Subject: Re: FW: Const-correctness in Xerces and TreeWalker
I think we need to think again about this, as it's not only
"createTreeWalker", the DOM document has all those createXXXX methods like
"createElement", "createAtttribute" ..., and then all those inherited
DOMNode interface like "removeChild", "replaceChild" ...etc. If we have to
overload each and every method with const modifier, it's not only a tedious
work but also PERFORMANCE may impact badly with all these overloaded virtual
functions. From my point of view, it just doesn't worth at all.
Performance is much more important. I would prefer leave it as is.
Tinny
----- Original Message -----
From: "Ingolf Steinbach" <in...@jena-optronik.de>
To: <xe...@xml.apache.org>
Sent: Friday, December 13, 2002 10:00 AM
Subject: Re: FW: Const-correctness in Xerces and TreeWalker
> * Jennifer Schachter <ja...@decisionsoft.com> [2002-12-13 15:55]:
> > This wouldn't help our problem: You cannot overload based on return
> > type...
> [...]
> > On Fri, 13 Dec 2002, Erik Rydgren wrote:
> [...]
> > > DOMDocument* DOMNode::getOwnerDocument();
> > > const DOMDocument* DOMNode::getOwnerDocument() const;
> [...]
> > > DOMTreeWalker* DOMDocument::createTreeWalker(DOMNode* node, and so
on...);
> > > const DOMTreeWalker* DOMDocument::createTreeWalker(const DOMNode*
node, and
> > > so on...) const;
>
> Note the "const" at the end of the lines. That's not overloading
> on return type (additionally, the second createTreeWalker() takes
> a "const DOMNode*"). So definitively the functions have a different
> signature which makes overloading possible.
>
> Regards
> Ingolf
> --
>
> Ingolf Steinbach Jena-Optronik GmbH
> ingolf.steinbach@jena-optronik.de ++49 3641 200-147
> PGP: 0x7B3B5661 213C 828E 0C92 16B5 05D0 4D5B A324 EC04
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: FW: Const-correctness in Xerces and TreeWalker
Posted by Tinny Ng <tn...@ca.ibm.com>.
I think we need to think again about this, as it's not only
"createTreeWalker", the DOM document has all those createXXXX methods like
"createElement", "createAtttribute" ..., and then all those inherited
DOMNode interface like "removeChild", "replaceChild" ...etc. If we have to
overload each and every method with const modifier, it's not only a tedious
work but also PERFORMANCE may impact badly with all these overloaded virtual
functions. From my point of view, it just doesn't worth at all.
Performance is much more important. I would prefer leave it as is.
Tinny
----- Original Message -----
From: "Ingolf Steinbach" <in...@jena-optronik.de>
To: <xe...@xml.apache.org>
Sent: Friday, December 13, 2002 10:00 AM
Subject: Re: FW: Const-correctness in Xerces and TreeWalker
> * Jennifer Schachter <ja...@decisionsoft.com> [2002-12-13 15:55]:
> > This wouldn't help our problem: You cannot overload based on return
> > type...
> [...]
> > On Fri, 13 Dec 2002, Erik Rydgren wrote:
> [...]
> > > DOMDocument* DOMNode::getOwnerDocument();
> > > const DOMDocument* DOMNode::getOwnerDocument() const;
> [...]
> > > DOMTreeWalker* DOMDocument::createTreeWalker(DOMNode* node, and so
on...);
> > > const DOMTreeWalker* DOMDocument::createTreeWalker(const DOMNode*
node, and
> > > so on...) const;
>
> Note the "const" at the end of the lines. That's not overloading
> on return type (additionally, the second createTreeWalker() takes
> a "const DOMNode*"). So definitively the functions have a different
> signature which makes overloading possible.
>
> Regards
> Ingolf
> --
>
> Ingolf Steinbach Jena-Optronik GmbH
> ingolf.steinbach@jena-optronik.de ++49 3641 200-147
> PGP: 0x7B3B5661 213C 828E 0C92 16B5 05D0 4D5B A324 EC04
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: FW: Const-correctness in Xerces and TreeWalker
Posted by Erik Rydgren <er...@mandarinen.se>.
Thanks, I became a bit worried there and I just HAD to check myself. And it
works, of course ( No false modesty here :) )
But you beat me to it.
/ Erik
-----Original Message-----
From: Ingolf Steinbach [mailto:ingolf.steinbach@jena-optronik.de]
Sent: den 13 december 2002 16:01
To: xerces-c-dev@xml.apache.org
Subject: Re: FW: Const-correctness in Xerces and TreeWalker
* Jennifer Schachter <ja...@decisionsoft.com> [2002-12-13 15:55]:
> This wouldn't help our problem: You cannot overload based on return
> type...
[...]
> On Fri, 13 Dec 2002, Erik Rydgren wrote:
[...]
> > DOMDocument* DOMNode::getOwnerDocument();
> > const DOMDocument* DOMNode::getOwnerDocument() const;
[...]
> > DOMTreeWalker* DOMDocument::createTreeWalker(DOMNode* node, and so
on...);
> > const DOMTreeWalker* DOMDocument::createTreeWalker(const DOMNode* node,
and
> > so on...) const;
Note the "const" at the end of the lines. That's not overloading
on return type (additionally, the second createTreeWalker() takes
a "const DOMNode*"). So definitively the functions have a different
signature which makes overloading possible.
Regards
Ingolf
--
Ingolf Steinbach Jena-Optronik GmbH
ingolf.steinbach@jena-optronik.de ++49 3641 200-147
PGP: 0x7B3B5661 213C 828E 0C92 16B5 05D0 4D5B A324 EC04
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: FW: Const-correctness in Xerces and TreeWalker
Posted by Ingolf Steinbach <in...@jena-optronik.de>.
* Jennifer Schachter <ja...@decisionsoft.com> [2002-12-13 15:55]:
> This wouldn't help our problem: You cannot overload based on return
> type...
[...]
> On Fri, 13 Dec 2002, Erik Rydgren wrote:
[...]
> > DOMDocument* DOMNode::getOwnerDocument();
> > const DOMDocument* DOMNode::getOwnerDocument() const;
[...]
> > DOMTreeWalker* DOMDocument::createTreeWalker(DOMNode* node, and so on...);
> > const DOMTreeWalker* DOMDocument::createTreeWalker(const DOMNode* node, and
> > so on...) const;
Note the "const" at the end of the lines. That's not overloading
on return type (additionally, the second createTreeWalker() takes
a "const DOMNode*"). So definitively the functions have a different
signature which makes overloading possible.
Regards
Ingolf
--
Ingolf Steinbach Jena-Optronik GmbH
ingolf.steinbach@jena-optronik.de ++49 3641 200-147
PGP: 0x7B3B5661 213C 828E 0C92 16B5 05D0 4D5B A324 EC04
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: FW: Const-correctness in Xerces and TreeWalker
Posted by Gareth Reakes <ga...@decisionsoft.com>.
Hi,
> 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?
We would then have to do the same to the methods inside of DOMTreeWalker.
I think this is OK. But what does DOMTreeWalker store? A DOMNode* or a
const DOMNode* as the root?
Gareth
--
Gareth Reakes, Head of Product Development +44-1865-203192
DecisionSoft Limited http://www.decisionsoft.com
XML Development and Services
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: FW: Const-correctness in Xerces and TreeWalker
Posted by Jennifer Schachter <ja...@decisionsoft.com>.
This wouldn't help our problem: You cannot overload based on return
type...
Cheers,
Jenn
On Fri, 13 Dec 2002, Erik Rydgren wrote:
> 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
>
--
Jennifer "Georgina" Schachter, Software Engineer +44-1865-203192
DecisionSoft Limited http://www.decisionsoft.com
XML Development and Services
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: FW: Const-correctness in Xerces and TreeWalker
Posted by Erik Rydgren <er...@mandarinen.se>.
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:bws@strongholdtech.com]
Sent: den 13 december 2002 15:24
To: xerces-c-dev@xml.apache.org
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:gareth@decisionsoft.com]
> Sent: Friday, December 13, 2002 8:32 AM
> To: xerces-c-dev@xml.apache.org; erik.rydgren@mandarinen.se
> 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: xerces-c-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> > >
> > >
> >
> > --
> > Gareth Reakes, Head of Product Development +44-1865-203192
> > DecisionSoft Limited http://www.decisionsoft.com
> > XML Development and Services
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> >
>
> --
> Gareth Reakes, Head of Product Development +44-1865-203192
> DecisionSoft Limited http://www.decisionsoft.com
> XML Development and Services
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: FW: Const-correctness in Xerces and TreeWalker
Posted by Brad Settlemyer <bw...@strongholdtech.com>.
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:gareth@decisionsoft.com]
> Sent: Friday, December 13, 2002 8:32 AM
> To: xerces-c-dev@xml.apache.org; erik.rydgren@mandarinen.se
> 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: xerces-c-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> > >
> > >
> >
> > --
> > Gareth Reakes, Head of Product Development +44-1865-203192
> > DecisionSoft Limited http://www.decisionsoft.com
> > XML Development and Services
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> >
>
> --
> Gareth Reakes, Head of Product Development +44-1865-203192
> DecisionSoft Limited http://www.decisionsoft.com
> XML Development and Services
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: FW: Const-correctness in Xerces and TreeWalker
Posted by Gareth Reakes <ga...@decisionsoft.com>.
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: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> >
>
> --
> Gareth Reakes, Head of Product Development +44-1865-203192
> DecisionSoft Limited http://www.decisionsoft.com
> XML Development and Services
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
--
Gareth Reakes, Head of Product Development +44-1865-203192
DecisionSoft Limited http://www.decisionsoft.com
XML Development and Services
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: FW: Const-correctness in Xerces
Posted by Erik Rydgren <er...@mandarinen.se>.
Oh the tedious work to change all surrounding code. Oh the horror.. HORROR I
say!
But of course the answer is yes. Seems like a good idea. =)
Regards
Erik Rydgren
Mandarinen systems AB
Sweden
-----Original Message-----
From: Gareth Reakes [mailto:gareth@decisionsoft.com]
Sent: den 9 december 2002 12:13
To: xerces-c-dev@xml.apache.org
Subject: Re: FW: Const-correctness in Xerces
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: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
--
Gareth Reakes, Head of Product Development +44-1865-203192
DecisionSoft Limited http://www.decisionsoft.com
XML Development and Services
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: FW: Const-correctness in Xerces
Posted by Gareth Reakes <ga...@decisionsoft.com>.
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: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
--
Gareth Reakes, Head of Product Development +44-1865-203192
DecisionSoft Limited http://www.decisionsoft.com
XML Development and Services
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org