You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Liviu Nicoara <ni...@roguewave.com> on 2006/02/06 17:20:54 UTC

23.deque.iterators question

Martin,

I am currently attempting to convert deque.iterators to the new driver.
The test, in the current form uses plain asserts. I can only speculate
that a large number of assertions being exercised and the inefficiency
of the former driver's assertion mechanism was the reason for that. Is
that true?

I am going to convert all to calls the new driver's rw_assert. Please
let me know if you want it otherwise.

Thanks,
Liviu

Re: 23.deque.iterators question

Posted by Martin Sebor <se...@roguewave.com>.
Liviu Nicoara wrote:
> Martin,
> 
> I am currently attempting to convert deque.iterators to the new driver.
> The test, in the current form uses plain asserts. I can only speculate
> that a large number of assertions being exercised and the inefficiency
> of the former driver's assertion mechanism was the reason for that. Is
> that true?
> 
> I am going to convert all to calls the new driver's rw_assert. Please
> let me know if you want it otherwise.

I don't have this test in fron of me but in general, some tests use
plain assert() to verify that the test itself is sane (e.g., that
pointers that must not be null are in fact non null). These should
probably just use the RW_ASSERT() macro (which does the same thing
as assert but independently of NDEBUG and can't be turned off).

Other tests might use the (old) RW_ASSERT() or RW_ASSERT_FILE() macros
to assert other types of test preconditions that are unrelated to what
is being tested (e.g., that the localedef utility successfully produced
a locale). These should be replaced by calls to the rw_error() function
when the test can continue processing after this error, or by rw_fatal()
when the error is not recoverable. The latter should only be used in
extreme cases since it makes the whole test exit at the point of the
call.

Martin