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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk