Re: [boost] Boost.Assert

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
me.
> 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
to
> 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.

boost_assert? boost_assertion_failed?
(boost_return_true_if_you_want_the_program_to_stop? ;-))

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
can
> provide it. In the future, I predict this will be in all C++ compilers, so
I
> 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__,
__LINE__))
>
> I think this needs another set of parentheses:
>
>   #define BOOST_ERROR(expr) ((expr) || // ...

Yep. Thanks.

--
Peter Dimov
Multi Media Ltd.