On 9/17/2013 4:20 AM, Quoth Jared Grubb:
Short-circuit is still possible because the hamcrest-assertions are partially bound. So: BOOST_CHECK_PREDICATE( A && B, (value)); becomes like "(A && B)(value)". The wrapping object around "A && B" would hold A and B as members andwould forward "value" according to short-circuit evaluation rules.
While I agree that you could do that, my point was that I'm not convinced that there would be any benefit in doing so. It seems to me that it would be more complex internally to do that, and ultimately more useful to display all the failing sub-conditions anyway (as I said before, "false && false && false" might indicate a different failure cause than "false && true && false", but short-circuiting would hide this distinction). Short-circuiting might be beneficial if you were doing a test like "p && p->Something()" but that doesn't seem like it fits into the BOOST_CHECK_PREDICATE syntax anyway. Unless you're going to make predicates such as "contains" (and all others) auto-dereference pointers, the final expression would have to be a bare object or reference anyway (not a pointer), so any predicate would fail if it were null even with short-circuiting. Or you'd have to define modifiers or something, eg: BOOST_CHECK_PREDICATE(!is_nullptr() && deref(contains(42) || contains(43)), (ptr_to_container)); (where "deref" will do "*x" before passing it to the underlying predicate). Which I'm not convinced is any prettier than the alternative of just having two separate checks. And even in this case you could handle non-short-circuiting gracefully -- deref could simply report failure without calling its internal sub-predicate if it gets passed a null pointer. This would even let you omit the leading null check.