From: "Peter Dimov" <[EMAIL PROTECTED]> > From: "Kevin S. Van Horn" <[EMAIL PROTECTED]> > > 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost