+1
All of these sound completely reasonable to me.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
[EMAIL PROTECTED] on 01/12/2000 05:41:07 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: DOMString (was: xalan-c Problem with Xerces initialization)
If we're going to change DOMString around, here's my wish-list. Most are
for performance. Some are to make DOMString more regular as an ADT. I've
prototyped all of them locally.
1) Move DOMString operator + (const DOMString &other) to be a helper
function rather than a member, i.e. operator+(const DOMString& lhs, const
DOMString& rhs). Then add overloads of operator+ to work symmetrically
with XMLCh*, i.e. operator+(const DOMString& lhs, const XMLCh *rhs) and
operator+(const XMLCh* lhs, const DOMString& rhs). In general, try to get
the operators to work symmetrically with DOMString and XMLCh*, since an
application that uses both SAX and DOM (like Xalan) often needs to them
together in a calculation. In most cases, an overloaded method that works
with both XMLCh* and DOMString can do the job much faster than one that
needs to convert to temporary DOMString's.
2) Add a member appendData() overloaded to append a single XMLCh.
Currently, doing this requires temporary conversion to DOMString's, a big
waste. Also, operator+=() would be nice.
3) Make the DOMString(const char*) constructor either be explicit, or make
it be a non-member transcoding utility.
4) Also, the DOMString(int) constructor is a mental trap, since programmers
will sometimes think this does an itoa conversion. Also, because
characters are integral types, something like DOMString('A') does not work
like it looks. In fact, the std::base_string<>(int) constructor was
purposely left out of the standard string class because of
these common confusions. Instead, I'd rather have a member called reserve
() or something similar.
5) It would be nice to have a reset() method. I see that the Xerces code
sometimes just assigns the old DOMString a literal 0. But that kicks off
the DOMString(int) constructor and then an assignment. I bet a
DOMString.reset() method would be much faster, avoiding the temporary
DOMString.
