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]>
>> I didn't imply that it was false. I asked whether this is a real
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk