I think BOOST_ASSUME is a good idea. But there must be some warning in code that says "this might change program behaviour". I have come across code where the asserts are written and can never be tested because the condition is usually complex and depends on the state and run time behaviour of the system. The good thing about asserts at run time is that they do not prevent the code from working (in case the assert is written incorrectly and never tested) -- in a complex function you might never see a particular condition occur. For example in a complex concurrent system, if the condition occurs at run time in a non debug build (due to let say some timing issue) and the assert was badly written, assert() would work ok, but __assume() would change the behaviour of code. Basically what I am saying is that BOOST_ASSUME() would behave differently on MSVC and non MSVC platforms. In one case it would not change anything on the other (MSVC) it would make the condition true. This could lead to debugging issues and must be documented. Balbir On 9/22/05, Rob Stewart <stewart@sig.com> wrote:
#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
That misses what BOOST_ASSUME should do when BOOST_DISABLE_ASSERTS is not defined. With BOOST_ASSERT enabled, BOOST_ASSUME should call both BOOST_ASSERT and __assume():
#include <boost/config.hpp> #if defined(BOOST_MSVC) # if defined(BOOST_DISABLE_ASSERTS) # define BOOST_ASSUME(e) __assume(e) # else # define BOOST_ASSUME(e) BOOST_ASSERT(e); __assume(e) # endif #else # define BOOST_ASSUME(e) BOOST_ASSERT(e) #endif