From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-11-14 11:32:36
From: "Peter Dimov" <pdimov_at_[hidden]>
> From: "Kevin S. Van Horn" <Kevin.VanHorn_at_[hidden]>
> > It's been six days since I posted this, without a single response, so
> > going to try again. Based on earlier discussions, I thought there might
> > be some interest in this. Does anyone have any problems with the
> > interface? Should I turn this into a formal proposal for submission to
> > Boost? Peter, how does this compare with the changes to
> > <boost/assert.hpp> you were planning to do / are doing?
> Sorry, I've been offline. I'll try to make the changes to assert.hpp ASAP
> we can base the discussion on the new version.
The new boost/assert.hpp is now in CVS, I'll copy it below for convenience:
# define BOOST_ASSERT(expr) ((void)0)
void assertion_failed(char const * expr, char const * function, char const *
file, long line); // user defined
} // namespace boost
#define BOOST_ASSERT(expr) ((expr)? ((void)0):
::boost::assertion_failed(#expr, BOOST_CURRENT_FUNCTION, __FILE__,
# include <assert.h>
# define BOOST_ASSERT(expr) assert(expr)
The main difference between this version and the old assert.hpp is that
BOOST_ASSERT now uses the standard assert by default, something that was
decided during our earlier discussions. 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.
The main differences between this header and your proposed version are:
- 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.
- 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.)
- there is no BOOST_ASSERT_MSG. I don't have a strong opinion here. As the
main purpose of BOOST_ASSERT is to replace the standard assert, and since
the file/line/function supply enough information, I haven't provided a
BOOST_ASSERT_MSG macro, but I'm not strongly opposed to having one, either.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk