SOURCE In-Reply-To: <200509261722.j8QHMRms015648@[...].com> 
stewart@[...].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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost