Hi Everybody, I see there are mixed opinions on use of __assume in BOOST_ASSERT. The chief concern is there are people using BOOST_ASSERT in "uncommon" (but still valid) ways, such as: - to show dialog box, but only in debug mode - using assert handler to throw during unit testing - possibly more These types of usage would be prohibited if we introduced __assume into BOOST_ASSERT, so basically this is a no-no from stability point of view (nobody wants his code broken). Btw. the second way can be dealt with with disabling __assume if assertion handler is defined. On the other hand some people (including me) consider __assume to be nice, helping optimization and suppressing annoying warnings. I see 3 options: 1. BOOST_ASSUME =============================================== Put __assume in BOOST_ASSUME and leave BOOST_ASSERT unmodified. Pros: - does not disturb existing code in any way Cons: - no existing code uses it, i.e. all existing libraries would have to be modified to take advantage of it; this will probably never happen so most of the code will not benefit - obscure: most of the people would be confused about it when seeing it for the first time 2. BOOST_ASSERT + define to enable assume (default: on) =============================================== Pros: - does enable assume on all the boost code, some user programs get somewhat smaller and faster without any intervention from the programmer Cons: - breaks user code which uses BOOST_ASSERT in "uncommon" way. Would require a change in docs that executing BOOST_ASSERT(false) is undefined behavior (i.e. different than std::assert) BOOST_ASSERT + define to enable assume (default: off) =============================================== Pros: - does enable assume on all the boost code, some user programs get smaller and faster with a simple -D"BOOST_ASSERT_USE_ASSUME" on command line. Cons: - only small number of users will know about that #define, so probably most of the code will not benefit. What do you think? Marcin