From: "Peter Dimov" <pdimov@[...].net> 
>  
>  #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@[...].com
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost