That was another thing that I had to fix up in the STL semantics code that I sent you. If I remember right (I'm away from my development machine right now), that NodeImpl took as its last argument an DOMString& optional argument with a NULL default value. There was only one constructor that actually provided that argument. With STL that resulted in an exception, becuase you cannot initialize a std::basic_string with a NULL pointer.
What I did was remove the initialValue argument from NodeImpl and fixed the only derived constructor that provided that argument and just directly set the value member in the derived constructor. That should eliminate a DOMString constructor for 95% of node creations. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, February 04, 2000 7:45 AM To: [EMAIL PROTECTED] Subject: RE: DOMString (was: xalan-c Problem with Xerces initialization) >>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
