In-Reply-To: <dg7jf6$uf6$1@sea.gmane.org> kalita@poczta.onet.pl (Marcin Kalicinski) wrote (abridged):
Have you considered modifying BOOST_ASSERT to use __assume on MSVC?
It looks to me as though this risks changing the semantics of BOOST_ASSERT in a way which might break existing code. As I read the documentation, currently code like: if (!p) { BOOST_ASSERT( false ); return; } is supported and meaningful. If BOOST_DISABLE_ASSERTS is true, the macro does nothing and the return statement is executed when p is 0. If we change the macro to instead expand to __assume, then the compiler will probably omit both return and the check against zero. The documented behaviour of the code will change. Although I sympathise with the view that a failed assert should be considered undefined behaviour, I personally find the current documented behaviour quite useful. I sometimes use assert as a convenient way of saying, "issue a warning message, but only in debug builds." If we use __assume, we need to clearly distinguish between the old and the new behaviours, at the point of assert. Specifically, I suggest we add a new macro, eg named BOOST_ASSUME(x), which expands to BOOST_ASSERT(x) by default and to __assume(x) when BOOST_DISABLE_ASSERTS is true. This latter case would be documented as causing undefined behaviour if x is false. Programmers can than change their code from BOOST_ASSERT to BOOST_ASSUME at their leisure. If they believe in defensive programming, they may leave some code as BOOST_ASSERT.
Microsoft docs for __assume are here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng /htm/msmod_36.asp
-- Dave Harris, Nottingham, UK.