Re: [boost] [assert] Proposed patch

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-07-06 09:21:57

Gennaro Prota wrote:
> On Thu, 6 Jul 2006 14:27:57 +0300, "Peter Dimov" <pdimov_at_[hidden]>
> wrote:
>
>> I know. Is this a real problem?
>
> Well, doesn't seem false to me :)

I didn't imply that it was false. I asked whether this is a real problem.

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

>> It will just encourage people to not use it.
>> Not that they need much encouragement. Almost everyone ignores
>> BOOST_ASSERT (and the users' requests to please not do so).
>
> I'll assume you mean "not to ignore". Well, all I can promise is that
> I'll change all asserts in dynamic_bitset to BOOST_ASSERT. I can't do
> more, sorry.
>
> 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. 
BOOST_ASSERT is just a baseline replacement for assert that attempts to 
strike a balance between the needs of the library developers (who would 
rather just use assert without thinking) and the needs of the library users 
(who at minimum need to be able to disable or trap all library assertions.) 
One important design goal of BOOST_ASSERT is for someone to be able to do a 
global search and replace in the Boost codebase, turning all 'assert's to 
BOOST_ASSERTs.

Unfortunately, BOOST_ASSERT doesn't work even in this minimalistic form; 
most developers just don't care. But at least the users who do care can do 
the global replace themselves. Do not make them jump through additional 
hoops just because.

> I would often desire a
> higher degree of control; one thing I can imagine is passing type
> information to assertion_failed(), so that I can see what library the
> assert is coming from and decide what to do with that.

I'm not sure where this type information can come from, as BOOST_ASSERT is 
only given an expression.