Re: [boost] [test] Interest in 'hamcrest'-style checks?

Subject: Re: [boost] [test] Interest in 'hamcrest'-style checks?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-09-16 18:32:46

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.