From: "Peter Dimov" <pdimov@mmltd.net>
Rob Stewart wrote:
In the (elided ;-) example, ++x has a side effect so while it doesn't affect whether __assume(false) is reached, the optimizer shouldn't elide the increment unless it can prove that the new value of x is not used. Are you suggesting that __assume(false) would override that?
Yes, I am. __assume( false ) asserts that this point is unreachable. Since ++x always completes, it follows that ++x is unreachable as well, so it can be elided.
If that is the behavior of __assume(false), or at least given that it is a reasonable interpretation of what it could do, then including __assume() in BOOST_ASSERT() seems a little dangerous. Its inclusion should only follow the examination of a large set of extant uses of BOOST_ASSERT() (and perhaps even assert()) to see what effect adding __assume() would have on the generated code. If there are reasonable cases in which the (possible) effects of using __assume() would be deleterious, then there are two possibilities: - Do not include __assume() in BOOST_ASSERT(), but consider adding BOOST_ASSUME() to enable explicit use. - Codify the counterexamples in another macro and document BOOST_ASSERT()'s __assume() functionality and point to the new macro for cases in which that isn't desirable. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;