|
Boost : |
From: Dave Harris (brangdon_at_[hidden])
Date: 2005-09-21 13:01:22
In-Reply-To: <dgmfeo$q1v$1_at_[hidden]>
kalita_at_[hidden] (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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk