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

From: Rob Stewart (stewart_at_[hidden])
Date: 2002-11-14 12:58:24

From: "Peter Dimov" <pdimov_at_[hidden]>
> 
> #elif defined(BOOST_ENABLE_ASSERT_HANDLER)
> 
> #include <boost/current_function.hpp>

I don't follow what this is about.  The "handler," as I
understand it, is assertion_failed() declared below, so why this
header?

> namespace boost
> {
> 
> void assertion_failed(char const * expr, char const * function, char const *
> file, long line); // user defined
> 
> } // namespace boost
> 
> 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.

It certainly seems appropriate.

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

This is a very good approach.

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

The good thing about the assertion_failed() approach is that the
library user can make this choice himself.

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

We find it invaluable to provide explanatory text along with the
expression that failed.  We often build strings -- at runtime --
that provide additional context information and description in
the message.

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