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-17 05:24:58

On Sat, Sep 17, 2011 at 1:08 AM, Ben Robinson <icaretaker_at_[hidden]> wrote:

> On Fri, Sep 16, 2011 at 3:19 PM, Gennadiy Rozental <rogeeff_at_[hidden]
> >wrote:
>
> > Ben Robinson <icaretaker <at> gmail.com> writes:
> >
> > As they say: I'll believe it, when I see it ;) Until that time this is
> > all too much vapor for me. As I mention in other post, you never
> explained
> > how this condition is checked and who is going to check it: compiler,
> > preprocessor, person.
> >
> > Gennadiy
> >
>
> My written communication skills could certainly be improved, I'll try
> again.
>
> When compiled for production, the compiler will generate a compiler error
> for failing predicates/conditions which are statically asserted (exactly
> the
> same functionality as the BOOST_MPL_ASSERT_* macros).
>
> When compiled for testing, the code will compile around the predicates, and
> during run-time, if the predicates/conditions fail, an exception is thrown.
>
> This allows shipping the code with the usual static assert functionality,
> but now enables writing run-time unit tests for both regression testing,
> and
> confirming that the predicates do in fact fail when they should.
>
> Is that a better explanation?
>

It would seem to me that, typically, removing a static_assert that would
fail for a particular instantiation will just push the compiler errors
further on down the code after the (removed) static_assert; i.e., the
static_assert is only meant to catch compiler errors early and in a readable
way.

Do you have a particular use case in mind?

- Jeff