Re: [boost] Proposed Boost Assert -- once again

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
I'm
> > going to try again.  Based on earlier discussions, I thought there might
> > be some interest in this.  Does anyone have any problems with the
proposed
> > 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
so
> 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:

#undef BOOST_ASSERT

#if defined(BOOST_DISABLE_ASSERTS)

# define BOOST_ASSERT(expr) ((void)0)

#elif defined(BOOST_ENABLE_ASSERT_HANDLER)

#include <boost/current_function.hpp>

namespace boost
{

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__,
__LINE__))

#else
# include <assert.h>
# define BOOST_ASSERT(expr) assert(expr)
#endif

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.