Okay, my head is spinning now. What started this whole thing was an
observation that AttrImpl (possibly among others) was transcoding and doing
unnecessary (unnecessary on most platforms at least) constructors for string
literals.
The best solution for within Xerces, is to avoid string literals totally and
use the array initialization form that Dean described
const XMLCh spaceColon = { chSpace, chColon };
I'm working on a basic_string semantics effort right which I hope to put on
our FTP site in a few hours and I'll try to incorporate the array
initialization fixes.
p.s. I have a few questions:
1) A lot of constructors (NodeImpl's for example) have code like
this->ownerDocument=ownerDoc;
this->namespaceURI = null; //DOM Level 2
this->prefix = null; //DOM Level 2
this->localName = null; //DOM Level 2
this->name=nam;
this->nType=nTyp;
Why the use of "this->", wouldn't
ownerDocument = ownerDoc;
be equivalent. Is this an artifact of the Java conversion, or is there some
subtle platform or compiler issue that this avoids.
2) Lazy implementation of constant strings
There are several occurances of this type:
static DOMString *nam = 0; // Will be lazily initialized to "#document"
DocumentImpl::DocumentImpl(): NodeImpl(null,
DStringPool::getStaticString("#document", &nam),
DOM_Node::DOCUMENT_NODE,
false)
{
This leaves a handful of strings dangling at the end of the process. What
would be so terrible wrong with (other than our transcoding discussion):
static DOMString nam("#document");
DocumentImpl::DocumentImpl(): NodeImpl(null,
nam,
DOM_Node::DOCUMENT_NODE,
false)
{
