> > However, given the generally accepted meaning of an assertion, I > have no problem with using BOOST_ASSERT for debug only tests and > BOOST_VERIFY for debug and release tests. (Another name might be > BOOST_CHECK.) I don't do Windows programming -- or at least I > haven't done any in a few years -- so I'm not wedded to any > connotation of "VERIFY."
They are called SMART_ASSERT and SMART_VERIFY now, after receiving a suggestion. Check it out - www.torjo.com/smart_assert.zip or http://aspn.activestate.com/ASPN/Mail/Message/boost/1644092 I will post an update soon. > > Another scheme I've used in the past is a manifest constant to > control such assertion macros at one more level: production > versus non-production builds. The idea is that, using my names > above, BOOST_ASSERT appears in release builds unless > BOOST_PRODUCTION_RELEASE is defined. The latter case compiles > away the assertion code. > Indeed. I have such a thing: BOOST_SMART_ASSERT_MODE (a macro that can be defined by the programmer) 0 - "release" 1 - "debug" If not defined, I take the defaults: - NDEBUG defined - "release" - NDEBUG not defined - "debug" > The rationale for that approach is that having assertions in a > release build means you get the performance benefit of optimized > code -- which is terribly important here -- while retaining the > assertions to validate conditions. Once the application has > proven itself in rigorous testing, one can define > BOOST_PRODUCTION_RELEASE, rebuild, do some testing, and release > the product. Thus, the release build with > BOOST_PRODUCTION_RELEASE defined gives you the ordinary behavior > of assert -- the assertions don't appear in the build. > True. Best, John _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
