From: Kevin S. Van Horn (Kevin.VanHorn_at_[hidden])
Date: 2002-11-14 17:03:16
Peter Dimov writes:
> The new boost/assert.hpp is now in CVS, I'll copy it below for
It's simplicity is certainly an advantage.
> The main difference between this version and the old assert.hpp is that
> BOOST_ASSERT now uses the standard assert by default,
Hmmm... I guess my previous objection to doing this by default doesn't
really hold here, because if NDEBUG is defined the assert() is a no-op.
However, a couple of quibbles:
1. The proper C++ header file is <cassert>, not <assert.h>.
2. I think using familiar terminology is preferable. Developers already
know what NDEBUG does and how to use it, so I would prefer that
BOOST_DISABLE_ASSERTS be renamed BOOST_NDEBUG.
> I've introduced separate BOOST_DISABLE_ASSERTS and
> BOOST_ENABLE_ASSERT_HANDLER macros since relying
> on the BOOST_DEBUG "magic values" to control behavior seemed inferior.
I agree. Nobody wants to try to remember such numeric codes.
> assertion_failed is declared but left undefined, the user is expected to
> supply a definition. Compared to a set_assert_handler approach, this has
> the advantage that the handler is guaranteed to be already active when
> static object constructors are being executed.
OK, I agree that this is cleaner, as long as the user only has to supply a
definition when BOOST_ENABLE_ASSERT_HANDLER is defined.
> there is no explicit support for throwing exceptions, and no standard
> exception class is defined. (Although it is trivial to define a handler
> that throws.) This is intentional. I don't believe that we, at Boost, want
> to encourage this particular programming practice (assertions that throw.)
I disagree, on two counts:
1. I've dealt with enterprise systems that do some run-time checks, but
for which crashing and core-dumping is not an option. In this case it is
preferred to abort the transaction (throw an exception), log the error,
and get on with handling other transactions.
2. A number of the Boost libraries currently throw exceptions for logical
errors. During development, I would rather that these do an assert(), so
I can inspect the core dump with my debugger. Rather than fight over
which is the correct behavior, it seems preferable to simply make it a
user option. I've been counting on Boost Assert to provide that
One might argue that a user can always get throwing behavior by using
BOOST_ENABLE_ASSERT_HANDLER, but I am of the opinion that one should
provide some standard options for commonly-desired behavior. If you like,
this could be in a separate header that #include's <boost/assert.hpp>.
Now I'll levy one criticism against my own Boost Assert proposal:
If you want assertions checked and exceptions thrown when they evaluate
false for a production system, then you probably don't want to do any
expensive tests. However, during development you probably want to turn on
all the checking and debugging options you can. A distinction needs to be
made between "light" tests and "heavy" tests; the option to throw an
assertion probably only makes sense for "light" tests.
> there is no BOOST_ASSERT_MSG. I don't have a strong opinion here.
I included BOOST_ASSER_MSG because its equivalent in STLport seemed to be
useful as I scanned through that code. I don't have any experience in
using STLport myself, though. For those who have used STLport's debug
mode, how useful have you found the additional error message information
on failed debug assertions?
BTW, if BOOST_ASSERT_MSG is included, we'll have to make sure that this is
still a no-op when BOOST_ENABLE_ASSERT_HANDLER is not defined and NDEBUG
is. In particular, we have to make sure that the error message doesn't
get printed out (the assert() already turns into a no-op).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk