> David N Bertoni wrote:
> >Except the current semantics for DOMString are like that of a Java
String,
> >which is always a reference, so representing null is pretty natural.
For a
> >class having more C++-like semantics (value semantics), it would be
really
> >weird to have an operator==(void*) that works like the original
> >DOMString's. Not to mention that the implementation would be kind of
> >difficult and strange. Did you have something in mind for this?
>
> Actually, DOMString seems to be somewhere between Java's and basic_string
<> semantics.
Oops, I really meant StringBuffer, not String.
> If it where like Java's it wouldn't let you modify it after construction.
I'll going to have to spend
> some time experimenting to see how to balance everything. I don't know
the answers yet. I'm thinking that
> DOMString would be immutable, but there would be overloads for operator=
that would make conversion to
> arbitrary basic_strings transparent and not require an intermediate
allocation.
If it's immutable, then operator=() is out of the question. Do you mean
conversion from DOMString to some other string type? Or conversion to
DOMString from some other string type?
I would really like to see XMLCh* as the representation for strings. I
think that's the simplest thing, and you can always copy that to a
basic_string<XMLCh> if you want. Also, there are plenty of manipulation
functions that will accept XMLCh* for times when you want to do read-only
operations.
Anything other than const XMLCh* will mean that Xalan will not be able to
use these interfaces internally, and consume them without lots of overhead.
At that point, we're pretty much back to the way it is now, where
transforming an instance of the Xerces DOM requires the overhead of nodes
that bridge the two abstract base classes.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
