Re: [boost] Re: Re: smart assert (was: ENFORCE/betterassertiontechnique)

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
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