>>From Andy's description of the new DOMString(int mustBeNull) function, I don't see where there is any construction of a DOMString.
You are correct. Once before while running the debugger I thought I saw calls to DOMString(unsigned int) when assigning null to a string, but checking the latest code, it looks like this just invokes operator =(DOM_NullPtr*), and this doesn't create a temporary. So, performance isn't suffering. So, if this is true, the big question is: who is using the DOMString(int) ctor? The answer is: although it is not being used for assignment or comparision, it is being used for initialization. For example, there are many, many calls like this: throw DOM_DOMException(DOM_DOMException::XXXX, null) where the second parameter is typed as a DOMString. Would a default parameter be cleaner? Now that we have operator+ and operator+= overloads that take XMLCh,in combination with the DOMString(int) ctor, we have a slight hole in our type system For example, the expectation would be that these two are the same: DOMString foo = 'Z'; ============ DOMString foo; foo += 'Z'; But they aren't. Fortunately, code is in place so the first case will trigger a run-time assertion, since DOMString(int len) asserts whenever len != 0. -Rob
