From: brangdon@cix.compulink.co.uk (Dave Harris)

In-Reply-To: <200509211851.j8LIp8VY019052@shannonhoon.balstatdev.susq.com> stewart@sig.com (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():

Why?

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 same.

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 platform.

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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;