Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2003-05-22 14:02:31


From: "John Torjo" <john_at_[hidden]>
>
> > > If VERIFY is used in MFC to mean an assert even in release mode then
> that
> > is
> > > probably the best name.
> > In MFC it doesn't have that meaning though. It means that the expression
> > passed to VERIFY will get evaluated in the release build but the result of
> > this expression will not get checked in release build.
>
> Right!
> However, I think this would be a great feature (and a good name -
> BOOST_VERIFY) - to allow the same behaviour as ASSERT in release as well.
> What do you think? Do you think of a better name?

We use -- after name translation -- the following:

BOOST_DEBUG_ASSERT
BOOST_ASSERT

We follow the philosophy of keeping assertions in production
code; they've kept us from losing lots of money when a program
runs wild. Therefore, we normally use (the moral equivalent to)
BOOST_ASSERT and only in some circumstances use
BOOST_DEBUG_ASSERT (such as to call a second code path to
validate normal calculations).

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

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.

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.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk