On Sep 15, 2011, at 3:54 AM, Ben Robinson wrote:
Thank you for your insight into some additional benefits of this capability.
Thank you for making my library properly testable!
I had not considered the convenience of debugging an actual run-time call stack vs. the compiler trace. I will design this library so that by setting a single breakpoint in the library, it will always give access to the call-stack leading up to the failed assertion.
Oo. Neat. Actually I was just imagining an integrated pretty-print facility like Abel was suggesting, that puts the failed type calculation into the exception string. For example, one of my typical tests BOOST_MPL_ASSERT(( mpl::equal<preorder_adj::type, mpl::vector<A,B,C,D,E,F,G,A> > )); currently fails with depth_first_search.cpp:85:1: error: No match for 'assertion_failed( mpl_::failed ************ boost::mpl::equal< boost::mpl::v_item<G, boost::mpl::v_item<F, boost::mpl::v_item<E, boost::mpl::v_item<D, boost::mpl::v_item<C, boost::mpl::v_item<B, boost::mpl::v_item<A, boost::mpl::vector<mpl_::na>, 0>, 0>, 0>, 0>, 0>, 0>, 0> , boost::mpl::vector<A, B, C, D, E, F, G, A> >::************ )' and instead it could throw an exception that includes the gold inside the ***s. Then when running the unit test in verbose mode, I could verify that the failures are failing for the right reasons. I don't know much Boost.Test (nor have I looked closely at metatest) but it may even be possible to verify this automatically. Cheers, Gordon