Re: [boost] Boost.Assert

From: Darin Adler (darin_at_[hidden])
Date: 2001-11-12 12:29:06

on 11/12/01 5:19 AM, Peter Dimov at pdimov_at_[hidden] wrote:

> * Off by default;

Why is this a design goal? I am comfortable with the fact that <cassert> is
on by default and I don't see the need to innovate here. The simplest
programs are ones where I'd want asserts to work rather than be ignored.

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.

I don't think that having the BOOST_ERROR macro adds significant
flexibility. I'd suggest removing it.

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).

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.

> #define BOOST_ERROR(expr) (expr || !boost_error(#expr, __FILE__, __LINE__))

I think this needs another set of parentheses:

  #define BOOST_ERROR(expr) ((expr) || // ...

    -- Darin