One issue with leaving the asserts in for release mode testing is that a common error is to include a condition in an assert that has a side-effect. This can make a debug executable work while the release mode version fails. So you can't really test the release mode with the asserts left in. The only real way is to run Boost Test in release mode. Robert Ramey Beman Dawes wrote:
Beman Dawes wrote:
At 05:46 PM 1/15/2005, Rene Rivera wrote:
Would a temporary "#undef NDEBUG" in Boost.Config, activated only while testing, work?
It is possible there may be cases where the #undef NDEBUG should only >> apply to <cassert>. So it might be better if it were given explicitly in the test program.
Might the most straightforward thing be for test modules to have
At 09:52 AM 1/16/2005, troy d. straszheim wrote: their >own NDEBUG-ignorant assert macro? The vast majority of the work could >just get done with a perl one-liner. I would expect people to forget to >add the #undef NDEBUG, and then you just get more tests creeping in that >don't do anything.
This whole discussion may be a bit of a red herring. I wonder how many Boost libraries still depend on assert for testing (as distinct from asserts in compiled libraries)? Many use Boost.Test.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost