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]
> > 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
> > 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
> When compiled for production, the compiler will generate a compiler error
> for failing predicates/conditions which are statically asserted (exactly
> 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,
> 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
Do you have a particular use case in mind?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk