Boost logo

Boost :

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>> 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

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at