In-Reply-To: <200509261722.j8QHMRms015648@shannonhoon.balstatdev.susq.com> stewart@sig.com (Rob Stewart) wrote (abridged):
(e) is false, then the __assume tells us the sequence won't be executed at all, and both it and the BOOST_ASSERT can be optimised away. Whatever it
If (e) is false, then BOOST_ASSERT takes some action, be it invoking assert() or something else.
Only if it's not optimised away. Here's my thinking. For clarity I'll write it like this, factoring out the common sub-expression: if (e) { BOOST_ASSERT( true ); __assume( true ); } else { BOOST_ASSERT( false ); __assume( false ); } The compiler knows that __assume(false) can never be reached so it can optimise away the whole "else" clause - provided it can prove that the BOOST_ASSERT always returns. In general it is dangerous to put other stuff in the same control block as __assume(false), because you don't know how clever the compiler will be about proving stuff like that. In this case you could argue that the compiler /cannot/ prove that BOOST_ASSERT will return; indeed in many cases it won't return. Even so I think it is a bit dangerous, but I suppose it doesn't really matter. -- Dave Harris, Nottingham, UK.