Re: [boost] Boost.Assert

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
what is
> > 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
they
> 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
user.

1. Leave BOOST_ASSERT to assert(). ('return true' from boost_error or
use -DBOOST_ASSERT=assert.)
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.