BOOST_ASSERT_IF(IF,THEN)
Dear all, 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. Any comments? -Thorsten
Hi Thorsten. Does BOOST_ASSERT ( ( IF ) && ( THEN ) ) help? Best regards, Jurko Gospodnetić
Am Donnerstag 12 Juni 2008 14:45:43 schrieb Jurko Gospodnetić:
Hi Thorsten.
Does BOOST_ASSERT ( ( IF ) && ( THEN ) ) help?
Hm, since the assert fails if ( IF ) or (THEN) evaluates to false I guess you actually mean BOOST_ASSERT ( (! IF ) || ( THEN ) ) where (THEN) is only tested if (! IF) is false which is exactly the case if ( IF ) is true. Hoping he got it right, -- Maik
Hi Maik
Am Donnerstag 12 Juni 2008 14:45:43 schrieb Jurko Gospodnetić:
Hi Thorsten.
Does BOOST_ASSERT ( ( IF ) && ( THEN ) ) help?
Hm, since the assert fails if ( IF ) or (THEN) evaluates to false I guess you actually mean BOOST_ASSERT ( (! IF ) || ( THEN ) ) where (THEN) is only tested if (! IF) is false which is exactly the case if ( IF ) is true.
Hoping he got it right,
Yup... you got it right... :-) Serves mi right for typing in a quick reply and not taking enough time to read my own post. :-) Best regards, Jurko Gospodnetić
Thorsten Ottosen:
Dear all,
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 ); ?
Peter Dimov skrev:
Thorsten Ottosen:
Dear all,
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
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_ASSERT( IF? THEN: true );
yes, but I find that these become anoyingly hard to read. Don't you?
No, imho, the radability is okay, but I rather see a problem that "THEN" needs to compile even if "IF" yields false at compile time. Therefore such a construct might be of limited use when working with template metaprogramming. Kind Regards, Martin.
participants (6)
-
Jurko Gospodnetić -
Maik Beckmann -
Martin Schulz -
Pete Bartlett -
Peter Dimov -
Thorsten Ottosen