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 Gareth Reakes <ga...@decisionsoft.com> on 2002/12/13 14:31:31 UTC
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
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