If there are no objections, I'd like to go ahead put in the changes
to DOMString that Robert suggested.
Robert, are your prototypes in complete enough to just put into
CVS? Or, if you would prefer, you could email them to me and I'll
look them over and put them in.
Thanks,
-- Andy
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 12, 2000 5:41 PM
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.
>
>
>
>
>
