Boost logo

Boost :

From: Pete Bartlett (pete_at_[hidden])
Date: 2008-06-13 17:10:35


>>> I often find myself in the need of the above assertion mechanism where
>>> the actual assertion should only checked if the first condition is true.
>>>
>>> Of course, we could write this as
>>>
>>> if( IF )
>>> BOOST_ASSERT( THEN );
>>>
>>> but this has the potential downside that the compiler cannot
>>> completely optimize away the function calls inside the if-statement.
>>
>> BOOST_ASSERT( !IF || THEN );
>>
>> or
>>
>> BOOST_ASSERT( IF? THEN: true );

>yes, but I find that these become anoyingly hard to read.
>Don't you?
>
>-Thorsten

Indeed. I don't think there is any room for maneuver with the
implementation. There are four cases:

i) BOOST_DISABLE_ASSERTS defined - macro has to expand to (void)(0)

or ii) BOOST_ENABLE_ASSERT_HANDLER defined - user is ok for expr to be
evaluated in BOOST_ASSERT so it is ok to assume that IF and THEN can be
evaluated in BOOST_ASSSERT_IF - thus implement as (!(IF) || THEN) ?
((void)0) : boost_assertion_failed(#THEN,...)

or iii) NDEBUG defined - macro has to expand to (void)(0)

or iv) "normal debug mode" - macro expands to if(IF) assert(THEN)

For me the real question is whether the maintainer sees sufficient demand
for it.

Pete


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk