So, we'll create a temporary empty DOMString and copy it into the existing
DOMString, instead of just calling DOMString.erase()? That sounds
needlessly inefficient. How about making a static DOMString, called
nullDOMString, and use that instead of null when assigning (and comparing)
to DOMString's. This will at least avoid the temporaries, and allow us to
remove the DOMString(int) ctor altogether. OK. I know we all hate static
DOMString's, but an empty one should be safe, right? Or if you want you
can define a global template function const T& null<class T>, and
specialize for particular types. This way you could avoid temporaries in
other DOM types that are currently being compared/set to null.
BTW, erase() is the Standard Library name for the function, but I'd be
equally jolly if we just had an override of deleteData(). We should try to
be consistent either way. I'd like to use this function in my code for
efficiency's sake and avoid any syntactic sugar that tries to make
perfectly good C++ look like Java<g>.
-Rob
Andy Heninger wrote:
DOMString::DOMString(size_t), for reserving buffer space, is removed.
But an overloaded constructor taking(int) remains, to avoid
breaking java-like code of the form
someDOMString = null;
There is enough usage of this construct that I prefer not to
break it, and, for better or worse, these DOM bindings do try
to be as compatible as reasonably possible with the Java.
Overloading on DOMNullPointer * doesn't work in this case because
it is ambiguous when null is defined to be 0.
The new overload is documented as being for handling nulls only,
and the implementation has an assert check for the passed value
being null. Not as nice as catching problems at compile time,
but better than nothing.
