Re: [boost] Is there interest in unit testing both passing and failing BOOST_MPL_ASSERTs?

Subject: Re: [boost] Is there interest in unit testing both passing and failing BOOST_MPL_ASSERTs?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-09-14 03:10:37

On Tue, Sep 13, 2011 at 11:55 PM, Ben Robinson <icaretaker_at_[hidden]> wrote:

> >
> > If you're just checking MPL assertions, then presumably there's a
> > predicate that can be evaluated without throwing.  Why not just feed
> > those predicates' results to regular runtime assertions?
> >
> > Thank you for considering my proposal.  You are correct in that my code
> has
> predicates, and I do want to ship my library with these predicates
> evaluated
> by a static assert, so that uses who incorrectly use the library, receive a
> compile error.  This library has a thorough set of unit tests,
> demonstrating
> the proper usage of the library with expected results.  However, I cannot
> write any unit tests for regression purposes, which would validate that a
> false predicate result will block compilation, because of course, that unit
> test would not compile.
>

I'm not following :(

If I wanted to validate that a false predicate results, then I would do
BOOST_STATIC_ASSERT(!predicate).

When I develop code with static asserts, I generally write a number of unit
> tests, prove that they do not compile, and then comment them out.  There is
> no automated regression testing.  There must be other solutions to this
> problem I am not aware of.
>

Okay, let me see if I understand now:  You want a way for the compiler to
ignore the static assertions and actually *try* to compile to errant code to
ensure that you do, in fact, get a compiler error (which would normally be
caught early on by the static assertion).  Is that right?

- Jeff