Vladimir Prus writes: > 1. I'd prefer to have BOOST_NDEBUG instead of BOOST_DEBUG, for > consistency with NDEBUG. I simply want BOOST_ASSERT to work for > debug builds. Or doesBOOST_DEBUG have non-empty initial value?
Yes, that was my original choice. I changed it to BOOST_DEBUG for two reasons: 1. That's the way it was in the existing (undocumented) <boost/assert.hpp>. 2. Experienced C/C++ programmers already know to define NDEBUG for optimized code, but unless they read the documentation for Boost Assert, they won't know to define BOOST_NDEBUG. Now consider someone who is just using one of the Boost libraries, but not Boost Assert. If that library uses Boost Assert (as it should), it will take a performance hit when BOOST_NDEBUG is not defined. The user won't know why this is happening, as he will have had no reason to read the Boost Assert documentation. I suppose one option would be to have a READ THIS FIRST section in the documentation, that users should read regardless of which library(ies) they intend to use. > 2. failed_exception can be safely derived from std::exception. Unlike > std::logic_error, it does not use std::string. Good point. > 3. Docs for BOOST_ASSERT say > 'Otherwise, if user has already provided a definition for BOOST_ASSERT, > the definition is left unchanged. > > Is this accurate? If user has provided its own definition for BOOST_ASSERT, > then calling the BOOST_ASSERT macro will do what user coded. You must > mean that if there's BOOST_ASSERT defined then <boost/assert.hpp> won't > change that definition. That's what I thought I said. I guess my wording was unclear. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
