I did a quick prototype before the holidays of replacing DOMString with a std::wstring subclass. Most of the conversion went easy, a one-to-one mapping of names. Some stuff like the DOMString(const char*) constructor and the DStringPool were trickier. For performance, I didn't see any difference for small documents, but once I started with 3MB+ documents, things started to drag really bad. My guess is that we'd sorely miss the custom memory management that DOMString does, the way it reduces fragmentation, etc. If we wanted to use a standard string class we'd probably need to port this stuff to a custom Allocator class and then use std::basic_string<XMLCh,CustomAllocator>. But this creates a new type, so an instance of this class would not be assignable to a std::wstring, right?
So, perhaps the easier route would be to make the interface of DOMString be more like std::wstring. Introduce standard names for the member functions and deprecate the old names. Give users fair warning that the old names will disappear in version X. That's the easy part. Dealing with some of the semantic issues, such as DOMStrings' distinction between "null" strings and strings with length==0, will be trickier. -Rob Curt Arnold wrote: >I had previously mentioned making DOMString's semantics match that of a >subset of wstring, so that a user could have a familiar behavior and it >would be possible (though not tested and supported) that you could redefine >DOMString to be derived from wstring. I haven't had any free time recently, >but I could take a shot at scoping the effect. Is it worth trying?
