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: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2011-09-15 18:30:16

Ben Robinson <icaretaker <at> gmail.com> writes:

> > I agree with the feedback that this interface should be separate from the
> BOOST_MPL_ASSERT_* family of macros.  I will move the logic I have
> implemented out of those macros, and create a similar family of macros, for
> unit testing purposes.  These macros will stand on their own, and should be
> usable as part of any C++ unit testing framework, including Boost.Test.  For
> this discussion, let's assume these new macros have the
> name BOOST_MPL_UNITTEST_*.

You obviosly free to implement this whatever way you prefer, but implementing
this as Boost.Test tool involve much more that simple exception being thrown. 

> The idea is to for a meta-program author to write their programs,

Write their programs or unit tests? Do you intend this to be part of the library
code or part of the unit test module?

> using BOOST_MPL_UNITTEST_* to statically assert various predicates and
> conditions required by the meta-program.  However, when the unit-tests
> instantiate the code, since they will define a symbol to #ifdef on, the

What symbol? Why do I need to do this if this statement reside in my unit test?

> implementation of BOOST_MPL_UNITTEST_* will not generate a compile error,
> but will instead instantiate an object which will throw a run-time exception
> upon instantiation.

How this macro will know that code would fail to compile?

I still do not see how you intend to check for compilability. Let's say I
develop single parameter template class Foo. How would I check that
instantiation Foo<int> fails to compile and report it at runtime?

Gennadiy