From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-12 12:57:48
From: "Darin Adler" <darin_at_[hidden]>
> on 11/12/01 5:19 AM, Peter Dimov at pdimov_at_[hidden] wrote:
> > * Off by default;
> Why is this a design goal?
Compatibility? Currently Boost is in "release mode" by default (because it
doesn't have a debug mode.) The rationale is (AFAIK) possible ODR problems.
> The name of the BOOST_ERROR macro and function don't make much sense to
> The name should have the word assert or assertion in it. I'd suggest
> changing the boost_error function name to boost_handle_false_assertion,
> boost_handle_failed_assertion, boost_handle_assertion_violation, or
> something like that. The name doesn't have to be verbose, but I'd like it
> at least be a verb, not a noun. Ideally, the name would also document the
> "return true if you want the program to stop" behavior.
On a more serious note, it's possible that the boost_error callback might be
reused by another error handling component (DbC?), so the 'generic' name
might be preferable.
> I don't think that having the BOOST_ERROR macro adds significant
> flexibility. I'd suggest removing it.
Some assert() implementations print the expression as well. Without an
additional macro layer, this results in an expression like
"(1 == 0) || !boost_error(\"1 == 0\", __FILE__, __LINE__)"
I think that
"BOOST_ERROR(1 == 0)"
is slightly better (although the name of the macro is open for debate.)
> I find it midly irritating that the proposal provides a declaration for a
> function that the user of the assert library is supposed to implement.
> That's not how the standard library handles this sort of thing. Perhaps
> there's a better approach (none comes immediately to mind).
Deliberate decision to avoid initialization order problems.
> I think it would be nice to include the function name for compilers that
> provide it. In the future, I predict this will be in all C++ compilers, so
> think it's prudent to plan for that. It's so much nicer to include the
> function name that I think it's worth a slight headache. But if there's no
> good way to detect the presence of the feature without including
> Boost.Config, that's probably a dealbreaker.
How, and where, should we include the function name? Do you mean as a
parameter to boost_error?
> > #define BOOST_ERROR(expr) (expr || !boost_error(#expr, __FILE__,
> I think this needs another set of parentheses:
> #define BOOST_ERROR(expr) ((expr) || // ...
-- 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