Re: DOM conformance tests

[Dean Roddey <dr...@charmedquark.com>]

"n a perfect world, it would probably be best to remove the unsigned
qualifiers from he arguments so that the behavior would parallel that of the
Java implementation."

Do we really want to adopt Java limitations like that, just to make those
few tests pass? Its really just a shortcoming of Java that they'd model for
which negative values have no meaning with a signed type.

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"Why put off until tomorrow what you can
put off until the day after tomorrow?"



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org

Re: DOM conformance tests

[Curt Arnold <ca...@houston.rr.com>]

If C++'s action on trying to cast a negative int to an unsigned int was an
exception, then using unsigned int's in the parameter list could be a good
thing.  But since you would expect that the count would often be calculated
by some expression that would involve subtraction, having a bunged
expression result in a silent conversion of a negative to a huge positive
value is a bad thing.  I think trading the safety of being able to detect
and signal negative values is worth the loss of range.  I wish I could find
some pithy citation to back me up, but I really shy away from using unsigned
except for qualifying types used to represent characters.

However, the "in a perfect world" comment, was trying to convey that it
probably didn't justify making changes, at least without some reflection.
Though it would be pretty easy to fix just those methods that participate in
the DOM test failure, unsigned int's are used in quite a few other calls and
it would probably be best to be consistant throughout.

There were a few other issues that I should have pointed out that I had to
work around in porting the Java DOM tests to Xerces-C.

The following code wouldn't compile since the
DOM_DOMImplementation(DOM_DOMImplementation&) constructor was declared
private.

void testDocumentGetImplementation ()  {
   //String desc = "The implementation attribute contains the
DOMImplementation object that handles this document.";
   Document doc = getStaffDocument();
   //
   //   can't access private constructor
   //
   DOMImplementation docImpl = getImplementation(doc);
   assert(docImpl.hasFeature("XML","1.0"));
}

One test didn't allow null as an argument since their wasn't a
DOM_Node(const DOM_NullPtr*) constructor.

   testEmployee.insertBefore(newChild,null);

Both of these were fairly simple to work around.  But any reason the
DOM_DOMImplementation constructor is private and why const DOM_NullPtr*
constructors couldn't be added to the DOM node types?


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org