Boost logo

Boost :

From: Dave Harris (brangdon_at_[hidden])
Date: 2005-09-18 10:16:33

In-Reply-To: <dg7jf6$uf6$1_at_[hidden]>
kalita_at_[hidden] (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 );

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:
> /htm/msmod_36.asp

-- Dave Harris, Nottingham, UK.

Boost list run by bdawes at, gregod at, cpdaniel at, john at