Re: [boost] [assert] Proposed patch

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-07-06 11:11:40

Gennaro Prota wrote:
> On Thu, 6 Jul 2006 16:21:57 +0300, "Peter Dimov" <pdimov_at_[hidden]>
> wrote:
>
>> I didn't imply that it was false. I asked whether this is a real
>> problem.
>
> I know :) I just wanted to say that it *is* a problem, and we can do
> something *easy* about it. I agree that it is not BOOST_ASSERT's
> responsibility to fix user/developer's errors, but a check wouldn't
> hurt anyone.

A check will hurt everyone who does a global assert -> BOOST_ASSERT replace 
and the code refuses to compile without a good reason.

>> BOOST_ASSERT is documented to resolve to assert by default. There is
>> nothing undefined about it.
>
> Yeah, there's nothing undefined about BOOST_ASSERT. It's about
> *assert*: invoking it with a parameter which doesn't end up in an
> integral expression produces undefined behavior (when NDEBUG is not
> defined).

You actually made me check. :-) This is not true for C99: it requires a 
scalar type, not an integral expression. So, unless we are 100% sure that 
the underlying assert macro isn't C99-compatible (and my guess is that most 
of them are), we can't diagnose this as an error.

I don't have C90, so I take your word for it.

>> You can of
>> course define BOOST_DYNAMIC_BITSET_ASSERT that offers a finer degree
>> of control, and I'm sure that some of your users will appreciate it.
>
> Then if every library author chooses his own solution... I was looking
> for consistency, which is the last refuge of the unimaginative.

Providing a consistent mechanism for per-library assertion control is 
probably technically doable, but this wasn't a design goal of BOOST_ASSERT. 
If you have a proposal along those lines (we can call it 
BOOST_LIBRARY_ASSERT, for instance), it might be worth considering.