I like option #3. Perhaps even make it so you can flip a switch and recompile to work with a plain std::string (8-bit chars). If you know that your documents will all be ASCII, this could be a big memory savings.
But what is it about the current state of the standard libraries that would be limiting to us? std::basic_string is a pretty simple class and if a particular platform doesn't have it, we might be able to use the portable version from www.stlport.org. I did a test a while back comparing the performance of DOMString to std::wstring, initializing, copying, etc. There really wasn't much of a difference (wstring slightly faster). Although I don't see this called out as a requirement in any spec, it seems that the VC++ 6.0 implementation of basic_string<> does copy-on-write semantics. But if a particular platform did not do this, the performance would compare poorly to DOMString. If we can't deal with basic_string, then I can't wait to see the problems we'll run into when the C++ port of Xalan is contributed. We're been using STL containers and algorithms heavily. -Rob Joe Gregorio wrote: >1. Don't change anything (except maybe add a larger red flag > in the documentation). >2. Change DOMString to have value semantics. >3. Drop DOMString in favor of wstring. > >Personally, I would prefer 3, but 2 is probably >the most reasonable given the current state of >Standard C++ libraries.
