On 10/21/2010 01:30 PM, Carl Ollivier-Gooch wrote:

Get off the point of conformance testing, as that's a side issue.

I'm not sure that it is. But I'll try to avoid mentioning it again.

The -real- issue is that there are internal checks that should be done to help API users with debugging. This is why we return errors. Yes, this is something the compliance tests check for, but that's not why they're there.

We return errors when things fail. That is an obviously well accepted programming practice. Failure to return an error flag of some kind when an operation fails is a bug (regardless of whether or not one is in a "release" mode.) That is distinct from helping users with debugging, which should be an implementation issue.

And yes, the implementation that's used is practice should be the one that's tested. What I'm saying is -specifically- that the -test- can be disabled in production mode. By this time, presumably the API user has code that is functioning properly and all those tests will pass anyway, so they're a waste of time. The only exception, I suppose, would be differences in behavior for different input, but those strike me as likely to be rare.

If the implementation is unusable in "testing" mode because it is doing some O(n^2) checking operation then have we really helped the developer?

I don't know about you, but when I use #ifndef NDEBUG, I -only- put things in those blocks that are pure tests with no side effects. The code that produces useful results (i.e., the production code) goes outside these.

Is there something you're trying to imply? :)

The debug-mode code does a lot of work on the side without affecting any output. That's the programming style I think makes sense here, too: write production code and decorate it with the necessary checks, some or all of which will be disabled in production code, without affecting what the production code does.

That's a great coding practice. However, I a) don't think it is appropriate for this particular case and b) don't see why you consider it part of the iMesh API rather than an implementation choice that we made.

So no, I don't think this is the beginning of a slippery slope. And I certainly disagree that there's anything involved that's focused specifically at compliance tests.

So if users never enable our "strict conformance" mode and we don't otherwise test for this does it really matter that the compliance test checked this and that our implementation passed? - jason