Anton Pevtsov wrote:
> Hi Martin,
> 
> Thank you for your comments. They are very helpful.
> Today I tried to port another test, 25_adjacent_find. New version is
> attached with its output. 
> 
> I have the question:
> 
> There is code in this test which calculates the difference between to
> current iterator positions: last.cur_ - first.cur_ where first and last
> are iterators (FwdIter for example). The cur_ variable has value_type*
> type. 
> So the difference last.cur_ - first.cur_ means differnce of two pointers
> and, if I understand correctly, has type ptrdiff_t.

Correct.

> 
> But in the test the results of such statements are casted to type
> size_t. size_t is unsinged 32-bit or 64-bit value, but the ptrdiff_t is
> signed. 

Correct.

> 
> And if the test fails the possible (I think it is almost impossible in
> reality :) ) cause may be incorrect difference between two values of
> iterators.

Yes, in theory this is possible.

> Assume that last.cur_ is less than first.cur_.

That would be a bug in test. OTOH, res.cur_ could (also in theory)
be less than first.cur_ if a bug std::adjacent_find() caused it to
return an iterator outside the range passed to it (the iterator would
have to be a BidirectionalIterator). However, the test iterators have
the capability to detect invalid operations such as incrementing past
the end of the range (or decrementing past the beginning), so this
case couldn't happen (unless, of course, the test iterator itself was
buggy).

> So the
> difference is negative but after casting to size_t it will have large
> positive value. Of course, the asserts will fail but the diagnostic
> information might be incorrect. I modified the test to avoid this. Is it
> correct?

It's good to be defensive and expect the unexpected, especially in
a test suite. But given what I said above, going to the trouble of
anticipating that the test suite itself might be buggy and trying
to be robust about it is unnecessary. After all, if we can't trust
the rest of the test suite infrastructure why should we trust our
own code that tries to handle such cases?

In short, in this test and others like it it's safe to assume that
the expression (first.cur_ <= res.cur_) && (res.cur_ <= last.cur_)
evaluates to true and it's also safe to assume that the value of
the expression (last.cur_ - first.cur_) is representable in size_t
without change.

I made a a minor change to the test to reflect the above and
to correct a gcc 4.0.2 compilation error having to do with the
explicit instantiation, and a few other minor tweaks. Let me
commit the test to SVN so you can see the "finished product."

Okay, here it is:
http://svn.apache.org/viewcvs.cgi?rev=345300&view=rev

Martin