From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-12 14:22:46
From: "Darin Adler" <darin_at_[hidden]>
> on 11/12/01 10:20 AM, Peter Dimov at pdimov_at_[hidden] wrote:
> > Assuming that we can test for this feature, what is the benefit? IOW
> > the use case where having the function name passed to boost_error help?
> My thought is that it's easier to guess quickly what went wrong from an
> assertion report if the function name is in there. For example, if I send
> out a version of my program for testing, and wire up assertions so that
> are reported to the end user, it's more likely that I can just figure out
> what's wrong if the function name is included in the message.
> That's all, nothing subtle.
Yes, I haven't explained myself well.
You have three options of wiring up assertions to be reported to the end
1. Leave BOOST_ASSERT to assert(). ('return true' from boost_error or
2. Provide your own BOOST_ASSERT.
3. Report the error to the user from boost_error.
(1) will automatically take advantage of __func__, (2) is fine as well. It's
only (3) that doesn't receive the function name.
The scenarios that I had in mind for overriding boost_error were throwing an
exception (presumably to be handled by a higher level component), logging
the error to a file, or performing cleanup before assert()ing. None of these
really needs the function name, although it can't hurt.
If we do add a 'const char * func' parameter to boost_error, the problems
are (1) how do we detect __func__ (#ifdef __func__ is no good) and (2) what
do we pass for 'func' when __func__ is not supported.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk