From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2006-07-06 10:55:42
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 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
>>> Are you sure that making BOOST_ASSERT fail
>>> when assert works a good idea?
>> It happens to work, and relies on undefined behavior. I think it's a
>> good idea to catch that.
>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
>>> It will just encourage people to not use it.
Well, BOOST_ASSERT is aimed at developers. I can't believe a
programmer wouldn't use it because it pointed out an error in his code
that he doesn't want to accept. And all that he needs doing to go on
is to add a "!=0" in 99.9% of the cases.
>> While we are at it, I've never liked too much the idea to switch off
>> (or on) all asserts from any boost library.
>This is a bit better than not being able to switch off all Boost asserts
>without also switching off all non-Boost asserts, isn't 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.
-- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk