You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Tobias Schütte <ts...@edvwl.de> on 2003/12/22 18:11:35 UTC
Xalan-C: Overriding XalanDOM - XalanDOMString
hi,
the whole Xalan-C XalanDOM classes are abstract and implemented for
example by the XalanSourceTree classes except XalanDOMString surely
because of performance.
But if the node data must be wrapped by an underlying in-memory
representation to XalanDOMString references, for example the conversion
from const XMLCh* to const XalanDOMString& in XercesParserLiaison done
by XercesDocumentBridge's XalanDOMStringPool, in worst case the data
must be copied each time to fit into the XalanDOMString vector model,
often there are many equal strings like names, etc. that can be cached
and reused, but double memory allocation or a cache lookup/string
compare overhead is always there.
I found a discussion about overriding the XalanDOM Tree structures at
http://marc.theaimsgroup.com/?l=xalan-dev&m=98403644905890&w=2, but my
question is how to effectively override the XalanDOM's String class, any
suggestion?? to do this, i think the data representation of the string
class must virtual.
mfg/regards
Tobias
AW: Xalan-C: Overriding XalanDOM - XalanDOMString
Posted by Tobias Schütte <ts...@edvwl.de>.
hi,
I do not know whether I expressed myself exactly enough, therefore I try
to describe a pseudo solution (theoretical!) for the interface from my
point of view, but before I do this, I wanna emphasize that I don't
intend to minimize the functionality of the XalanDOMString interface or
move to "just using a null-terminated array of characters".
Instead I intend to define a base class for XalanDOMString, for example
call it XalanString, without any data members but with the same
interface as XalanDOMString to keep the existing functionality.
After renaming a copy of XalanDOMString.hpp to XalanString.hpp, removing
the data members, declaring the member functions, that directly
manipulate m_data and m_size in XalanDOMString, pure virtual in
XalanString, moving all static functions and all member functions, that
do not directly manipulate m_data and m_size, from XalanDOMString to the
base class (to keep inlining/non-virtualness), XalanDOMString is derived
from XalanString and is the default implementation of XalanString,
without any change of XalanDOMString's interface.
After that the XalanDOM classes (XalanNode) should return const
XalanString references instead of XalanDOMString, but all XalanDOM
implementation code (XalanSourceTree), samples and user applications
that uses XalanDOMString to store Strings don't have to change, because
they can continue using XalanDOMString as they did before (but perhaps
can be tweak, see Advantages below).
Disadvantages:
- performance loss because of more virtual functions, don't know how
much this would be, but I'm not afraid about that, because the whole
XalanDOM is pure virtual
Advantages:
- full virtual XalanDOM, more flexibility
- perhaps more performance at xerces brigde, if xerces-c's strings were
wrapped directly (read-only XalanString2XercesWrapper) without extra
XalanDOMString pool
Tobias
-----Ursprüngliche Nachricht-----
Von: david_n_bertoni@us.ibm.com [mailto:david_n_bertoni@us.ibm.com]
Gesendet: Mittwoch, 24. Dezember 2003 04:05
An: xalan-dev@xml.apache.org
Betreff: Re: Xalan-C: Overriding XalanDOM - XalanDOMString
Hi Tobias,
This has always been a problem. Originally, I wanted to define a very
minimal interface for a string class, call it XalanDOMString, and use
that
class. The problem was I could not really get anyone to agree on what
the
minimal interface should be. For example, making the characters
available
as a null-terminated array of characters, like
std::basic_string::c_str()
is almost a necessity, because we are forced to interoperate with the
Xerces-C SAX classes, which use null-terminated arrays of characters.
Unfortunately, I don't think that's a very good design principle for an
abtract base class. Also, I'm a little concerned about performance
problems with lots of extra virtual function class on XalanDOMString.
Unfortunately, I don't believe there's any way we can move to just using
a
null-terminated array of characters, like the Xerces-C DOM interfaces
use.
However, if you would like to make a proposal for a minimal string
class,
we can certainly have a discussion about that class, and, if we can come
to
a consensus, we could move to a new set of interfaces in Xalan-C 2.0.
Dave
Tobias Schütte
<ts...@edvwl.de> To:
<xa...@xml.apache.org>
cc: (bcc: David N
Bertoni/Cambridge/IBM)
12/22/2003 06:11 Subject: Xalan-C:
Overriding XalanDOM - XalanDOMString
PM
Please respond
to xalan-dev
hi,
the whole Xalan-C XalanDOM classes are abstract and implemented for
example by the XalanSourceTree classes except XalanDOMString surely
because of performance.
But if the node data must be wrapped by an underlying in-memory
representation to XalanDOMString references, for example the conversion
from const XMLCh* to const XalanDOMString& in XercesParserLiaison done
by XercesDocumentBridge's XalanDOMStringPool, in worst case the data
must be copied each time to fit into the XalanDOMString vector model,
often there are many equal strings like names, etc. that can be cached
and reused, but double memory allocation or a cache lookup/string
compare overhead is always there.
I found a discussion about overriding the XalanDOM Tree structures at
http://marc.theaimsgroup.com/?l=xalan-dev&m=98403644905890&w=2, but my
question is how to effectively override the XalanDOM's String class, any
suggestion?? to do this, i think the data representation of the string
class must virtual.
mfg/regards
Tobias
Re: Xalan-C: Overriding XalanDOM - XalanDOMString
Posted by da...@us.ibm.com.
Hi Tobias,
This has always been a problem. Originally, I wanted to define a very
minimal interface for a string class, call it XalanDOMString, and use that
class. The problem was I could not really get anyone to agree on what the
minimal interface should be. For example, making the characters available
as a null-terminated array of characters, like std::basic_string::c_str()
is almost a necessity, because we are forced to interoperate with the
Xerces-C SAX classes, which use null-terminated arrays of characters.
Unfortunately, I don't think that's a very good design principle for an
abtract base class. Also, I'm a little concerned about performance
problems with lots of extra virtual function class on XalanDOMString.
Unfortunately, I don't believe there's any way we can move to just using a
null-terminated array of characters, like the Xerces-C DOM interfaces use.
However, if you would like to make a proposal for a minimal string class,
we can certainly have a discussion about that class, and, if we can come to
a consensus, we could move to a new set of interfaces in Xalan-C 2.0.
Dave
Tobias Schütte
<ts...@edvwl.de> To: <xa...@xml.apache.org>
cc: (bcc: David N Bertoni/Cambridge/IBM)
12/22/2003 06:11 Subject: Xalan-C: Overriding XalanDOM - XalanDOMString
PM
Please respond
to xalan-dev
hi,
the whole Xalan-C XalanDOM classes are abstract and implemented for
example by the XalanSourceTree classes except XalanDOMString surely
because of performance.
But if the node data must be wrapped by an underlying in-memory
representation to XalanDOMString references, for example the conversion
from const XMLCh* to const XalanDOMString& in XercesParserLiaison done
by XercesDocumentBridge's XalanDOMStringPool, in worst case the data
must be copied each time to fit into the XalanDOMString vector model,
often there are many equal strings like names, etc. that can be cached
and reused, but double memory allocation or a cache lookup/string
compare overhead is always there.
I found a discussion about overriding the XalanDOM Tree structures at
http://marc.theaimsgroup.com/?l=xalan-dev&m=98403644905890&w=2, but my
question is how to effectively override the XalanDOM's String class, any
suggestion?? to do this, i think the data representation of the string
class must virtual.
mfg/regards
Tobias