From: John Torjo (john_at_[hidden])
Date: 2003-05-23 00:21:43
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk