I have been playing with a derivitive of 1_0_1 where I've morphed the
definition of DOMString to match a subset of the exposed methods of an
std::basic_string<XMLCh>.  This both provides familiar behavior when using
the DOMString implementation (no more remembering when to clone or not) and
allows a developer to typedef DOMString as std::basic_string<XMLCh> either
for testing (to find if a bug is in DOMString to the other parts of the
code) or when he desires only one string class.

At the current time, my source will build and run DOMCount with the
USE_STL_STRING symbol defined and the Disable Language Extensions unchecked.
In this mode, DOMString is just an alias for basic_string.

When USE_STL_STRING is undefined, a DOMString class is used but its methods
have been redefined to align with STL's conventions.  Currently, all the
non-DOMString.cpp modules will compile (with no #ifdef's), but I haven't
successfully modified the previous DOMString implementation to fit the new
definitions.

Here are the issues that I ran into in other parts of the code:

*       NodeImpl::NodeImpl : These take a DOMString& as a final argument for
initialValue.  All but one of the derived constructors that call this pass a
null for the final argument causing an exception using STL.  I've removed
the last argument and explicit set the value in the one derived constructor
that tried to set the initialValue (I think it was ProcessingInstruction)

*       DOMString::DOMString(int length)'s functionality was replaced with
DOMString::reserver(int length)

*       Tests for null and empty strings that were typically done with (val
== null || val.length() == 0) are done with (val.empty())

*       appendData, substringData, insertData are now append, substr and
insert

*       DOMString constructors with char constants have now been replaced
with XMLCh array initialization

*       The lazy construction of DOMString's from the pool for
"#cdata-section" et al have been replaced (see CDataSectionImpl.cpp et al
for details) eliminating DOMString construction and transcoding on node
creation

*       all clone's have been removed

*       calls to equals() have been replaced as compare() == 0 (with strcmp
semantics)

*       DOM_DOMImplementation::hasFeature performs case insensitive check
for XML


The down side

A user cannot directly pass char*'s into arguments that take DOMString's.
However an operator=(DOMString&,const char*) could be defined so that you
could do something like

        DOMString asterisk = "*";
        something.getElement(asterisk);

DOMPrint.cpp breaks repeatedly since transcoding can not longer be part of
DOMString (since it isn't part of STL).  However, it should be fairly simple
to do transcoding as a methods that work on DOMString's instead of members
of DOMStrings.


If anyone wants a snapshot of my code base, email me and I can send it to
you as a zip file.  If anyone is interested and feels really comfortable (or
more comfortable than I am) with DOMString internals and wants to take a
shot at morphing the implementation so it has value semantics, I'd love to
pass that one off.  But if not, I'll give it a shot.

Reply via email to