From: Rob Stewart (stewart_at_[hidden])
Date: 2005-09-26 12:22:27
From: brangdon_at_[hidden] (Dave Harris)
> In-Reply-To: <200509211851.j8LIp8VY019052_at_[hidden]>
> stewart_at_[hidden] (Rob Stewart) wrote (abridged):
> > 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():
> Consider the sequence:
> BOOST_ASSERT(e); __assume(e)
> Suppose (e) is true. Then BOOST_ASSERT does nothing, so why
> invoke it? If
Because you don't know that it is true at compile time.
> (e) is false, then the __assume tells us the sequence won't be executed at
> all, and both it and the BOOST_ASSERT can be optimised away. Whatever it
If (e) is false, then BOOST_ASSERT takes some action, be it
invoking assert() or something else. If you omit that call to
BOOST_ASSERT, then you simply get __assume(e) and that's not the
> is you want BOOST_ASSERT to do, you can't rely on it happening. It will
> depend on how clever the optimiser is, which will vary from platform to
I don't understand your point. Either (e) is true and
BOOST_ASSERT will do nothing (other than evaluate (e)), or it is
false and BOOST_ASSERT will fire.
The point is that *if* (e) is true, __assume(e) provides
information that the optimizer can use to generate better code.
> In addition, it evaluates (e) twice. That's bad practice for a macro. It
That's an assumption I'm not prepared to make. My guess is that
the compiler uses the information to generate code but doesn't
consult that expression at run time (as with sizeof).
> would be acceptable if it were necessary (and we certainly hope (e) has no
> side effects and that its value doesn't change between the assert and the
> assume) but here there is no need for it.
I do see a need for it and I doubt the side effects would occur.
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk