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.
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.
I have been able to get Andy's samples up and running with the CVS version, I had to
hack the IDOMParser.hpp and .cpp files to compensate for some changes to DTDValidator
that occurred since the
sample was written. The output directories and file names also needed to be provided
for the Release versions of idom and ithreadtest projects.
The benchmark files seemed to be missing ado.xml and the "wc data" directories. I'm
also doing some profiling of the current behavior (using TrueTime) before diving in.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
