From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-07-25 04:38:21
Gennadiy Rozental wrote:
> > I most certainly don't want to make (most of) MPL's tests
> > run-time. Right now I can determine if the compiler passes
> > the test by simply compiling the latter, and I would like to
> > keep it this way.
> Let say some algorithm like find_if is failing (not
> compilation error but static assert), i.e. it's result is
> different them you expected. Would not you be interested to
> know what type was computed in fact?
I can query that without making the test run-time:
typedef mpl::list_c<int,1,0,5,1,7,5,0,5> values;
typedef mpl::find< values, mpl::integral_c<int,7> >::type iter;
If I compile it, I'll get this:
boost/mpl/aux_/debug_print.hpp(27) : error C2039: 'not_existing_memeber' :
is not a member of 'integral_c<int,7>'
Good enough, IMO.
> How are you gonna "debug" you algorithms?
Like the above.
> And how are you gonna keep track of tests that are passing,
> supposed to fail and so on.
All tests should pass. Tests that cannot be _compiled_ because of an absent
compiler feature are (should be) guarded accordingly, e.g.:
// meta_fun test
> What if, let say algorithm find_if working in all cases but
> empty type sequence? You will just say find if is unusable
> while in fact it could be perfectly used in majority of cases.
I am not interested in such granularity for test cases, at least for now.
It's not a type traits library. There is no technical reasons for 'find' (or
any other algorithm) to not work on empty sequences, and it should. If the
'find' test case fails, for whatever reasons, it should be looked at and
fixed. In any case, a need for diagnosing/locating separate failures doesn't
necessary imply move to run-time testing.
> This list of "what if" could be prolonged. Is there specific
> reason why you want to keep tests compile-time?
Yes - it would make my life more painful :). In particular, I would lose an
ability to test what I am currently working on from the IDE (or at least it
would require non-trivial efforts to setup the whole thing).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk