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