From: "Peter Dimov" <[EMAIL PROTECTED]> > From: "Rob Stewart" <[EMAIL PROTECTED]> > > > > 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.
I should point out that in my particular situation, we don't mind our applications coming to a crashing halt. However, we need to determine very quickly what's wrong and get them going again. Thus, having a lucid and detailed explanation of the error condition is important. > Interesting perspective. The question that springs to mind is: would you > abandon your ASSERT macro in favor of BOOST_ASSERT_MSG, if it existed? Why > would you want to do that? IOW, what is the intended audience of > BOOST_ASSERT, Boost library developers or "end users"? I'm sorry this reply is so late, but it's here finally. If there was a cross-platform, flexible, and helpful facility available from Boost to replace what we currently use, I would certainly work to replace existing code with Boost's. The reasons are that it would encourage knowledge of Boost and it would have a good chance of becoming standard C++ in the future. I see no reason to retain and maintain code that duplicates what's available from Boost when we can make the replacement easily enough. So, what is the intended audience of BOOST_ASSERT? I think all C++ code, in Boost and in application code. Can a single facility work equally well in both environs? Yes. I can say that because we have assertion macros (and machinery behind them) that are used by library and application code. (The library code is used by various applications throughout the company, serving many different purposes, so don't get the idea that it is really application level code.) The difficult question is how to reconcile the message type you require with the dynamically generated messages I mentioned. Obviously, if BOOST_ASSERT could take a std::string or std::ostringstream as easily as a char const *, then we're in business. IOW, if BOOST_ASSERT merely passes its message argument to boost::assertion_failed(), and boost::assertion_failed() could be overloaded to take different parameter types for the message argument, then the BOOST_ASSERT client can supply different message types and corresponding boost::assertion_failed() overloads. Does that seem reasonable? A capability like that would also make converting to BOOST_ASSERT easier. The reason is that our macro could be a simple wrapper for BOOST_ASSERT as an initial step toward complete conversion. -- Rob Stewart [EMAIL PROTECTED] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
