Peter Dimov writes: > The new boost/assert.hpp is now in CVS, I'll copy it below for > convenience:
It's simplicity is certainly an advantage. > The main difference between this version and the old assert.hpp is that > BOOST_ASSERT now uses the standard assert by default, Hmmm... I guess my previous objection to doing this by default doesn't really hold here, because if NDEBUG is defined the assert() is a no-op. However, a couple of quibbles: 1. The proper C++ header file is <cassert>, not <assert.h>. 2. I think using familiar terminology is preferable. Developers already know what NDEBUG does and how to use it, so I would prefer that BOOST_DISABLE_ASSERTS be renamed BOOST_NDEBUG. > 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. I agree. Nobody wants to try to remember such numeric codes. > 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. OK, I agree that this is cleaner, as long as the user only has to supply a definition when BOOST_ENABLE_ASSERT_HANDLER is defined. > 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.) I disagree, on two counts: 1. I've dealt with enterprise systems that do some run-time checks, but for which crashing and core-dumping is not an option. In this case it is preferred to abort the transaction (throw an exception), log the error, and get on with handling other transactions. 2. A number of the Boost libraries currently throw exceptions for logical errors. During development, I would rather that these do an assert(), so I can inspect the core dump with my debugger. Rather than fight over which is the correct behavior, it seems preferable to simply make it a user option. I've been counting on Boost Assert to provide that functionality. One might argue that a user can always get throwing behavior by using BOOST_ENABLE_ASSERT_HANDLER, but I am of the opinion that one should provide some standard options for commonly-desired behavior. If you like, this could be in a separate header that #include's <boost/assert.hpp>. Now I'll levy one criticism against my own Boost Assert proposal: If you want assertions checked and exceptions thrown when they evaluate false for a production system, then you probably don't want to do any expensive tests. However, during development you probably want to turn on all the checking and debugging options you can. A distinction needs to be made between "light" tests and "heavy" tests; the option to throw an assertion probably only makes sense for "light" tests. > there is no BOOST_ASSERT_MSG. I don't have a strong opinion here. I included BOOST_ASSER_MSG because its equivalent in STLport seemed to be useful as I scanned through that code. I don't have any experience in using STLport myself, though. For those who have used STLport's debug mode, how useful have you found the additional error message information on failed debug assertions? BTW, if BOOST_ASSERT_MSG is included, we'll have to make sure that this is still a no-op when BOOST_ENABLE_ASSERT_HANDLER is not defined and NDEBUG is. In particular, we have to make sure that the error message doesn't get printed out (the assert() already turns into a no-op). _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
