Did you remove print() and println()?
-joe
Andy Heninger wrote:
>
> I'm about to commit a version of DOMString with many of the changes that
> have been discussed in this thread, but not all, at least not yet.
>
> Differences from Robert's original list (the message that started this
> thread) are these:
>
> o I did not remove the DOMString(char *) constructor. There's
> just too much use of it, much of it in code outside of my
> control.
>
> I did add the new member function (Robert's suggestion)
> static DOMString DOMString::transcode(char *)
> which does the same thing but lets you be explicit about it.
> And is nicely symmetric with the existing transcode().
>
> o 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.
>
> o Erase() isn't in. I think that it should be, but am unsure
> of the name. DOMString already has deleteData(), taken from
> the CharacterData interface in the W3C DOM spec, along with
> appendData(). Maybe a no-parameters overload of this would
> be better.
>
> o The XMLStrL is not in. I'd like to see something like it,
> but I don't think that I fully understand everything about
> this problem yet. I'm also a little worried about having a
> function whose efficiency of operation can not be known by
> a developer - it could be a compile time constant or an
> expensive call to a transcoding service.
>
> The rest is there, including all of the proposed overloads of + and +=,
> and a fix to appendData() to make it work efficiently with strings
> with reserved buffer space.
>
> -- Andy
--
-------------------------------------
Joe Gregorio MTS System Corp
Program Manager www.mts.com
