In-Reply-To: <dgmfeo$q1v$1@sea.gmane.org> kalita@poczta.onet.pl (Marcin Kalicinski) wrote (abridged):

I think generally this is a good idea, but it has a small problem. I would expect that BOOST_ASSUME should turn into __assume when compiled in "release" mode of MSVC. As of above proposed solution this is not the case - user additionally needs to define BOOST_DISABLE_ASSERTS to get __assume. So when NDEBUG is defined and BOOST_DISABLE_ASSERTS is not (I think this is 99% of cases, because few people actually use BOOST_DISABLE_ASSERTS), BOOST_ASSUME will expand to BOOST_ASSERT and the whole thing will be useless.

I did not use NDEBUG because BOOST_ASSERT doesn't, and I didn't want to revisit that decision. I imagine the policy is to use fine-grained flags and then add: #ifdef NDEBUG #define BOOST_DISABLE_ASSERTS #endif in a user-editable header somewhere. Arguably there should be a BOOST_DISABLE_ASSUMES, too, but for now I'll use BOOST_DISABLE_ASSERTS.

# define BOOST_ASSUME(e) { BOOST_ASSERT(e); if (e); else __assume(0); }

That evaluates e twice, and if e is false it is not clear whether the assert will actually do anything because it could be optimised away. I think: # define BOOST_ASSUME(e) __assume(e) is simpler and better.

There's also a question what should BOOST_ENABLE_ASSERT_HANDLER do with BOOST_ASSUME? Should it invoke the handler if condition is false?

Only if BOOST_DISABLE_ASSERTS is not defined. So the full code would be: #include <boost/config.hpp> #if defined(BOOST_MSVC) && defined(BOOST_DISABLE_ASSERTS) # define BOOST_ASSUME(e) __assume(e) #else # define BOOST_ASSUME(e) BOOST_ASSERT(e) #endif -- Dave Harris, Nottingham, UK.