Subject: Re: [boost] Is there interest in unit testing both passing and failing BOOST_MPL_ASSERTs?
From: Ben Robinson (icaretaker_at_[hidden])
Date: 2011-09-14 02:55:31
> If you're just checking MPL assertions, then presumably there's a
> predicate that can be evaluated without throwing. Why not just feed
> those predicates' results to regular runtime assertions?
> Thank you for considering my proposal. You are correct in that my code has
predicates, and I do want to ship my library with these predicates evaluated
by a static assert, so that uses who incorrectly use the library, receive a
compile error. This library has a thorough set of unit tests, demonstrating
the proper usage of the library with expected results. However, I cannot
write any unit tests for regression purposes, which would validate that a
false predicate result will block compilation, because of course, that unit
test would not compile.
When I develop code with static asserts, I generally write a number of unit
tests, prove that they do not compile, and then comment them out. There is
no automated regression testing. There must be other solutions to this
problem I am not aware of.
I considered two solutions which both basically apply the FTSE. First, the
proposal I submitted allows the library author to place BOOST_MPL_ASSERT_*
macros directly in the library, but then conditionally alters these macros
to generate the desired run-time error in a unit test environment. The
second solution would involve the library author calling a
new macro/function/etc which would conditionally call the
corresponding BOOST_MPL_ASSERT_* macro, or instead generate a run-time
error. The second solution increases the surface area static asserts, so I
favored the first solution.
Doesn't seem like we need a new tool. The very point of
> BOOST_MPL_ASSERT_* is to catch errors at compile time. If you want
> something else, there are plenty of appropriate choices.
> If something already exists which meets my stated requirements above, I
would greatly appreciate a pointer in the right direction. I hope I have
more clearly communicated which my proposal is trying to achieve.
Thank you (really), :)
Ben Robinson, Ph.D.
> Dave Abrahams
> BoostPro Computing
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk