[boost] Re: Re: Re: Re: Formal Review: Template Metaprogramming L ibrary(MPL)

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-07-26 21:53:56

Gennadiy Rozental wrote:
> > 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;
> 
> >     BOOST_MPL_AUX_DEBUG_PRINT(iter::type);
> 
> Does not seems very convinient cause you need to change the 
> code every time

Good thinking ;), now I don't:

    BOOST_MPL_ASSERT_IS_SAME(iter::type, int);

F:\home\depot\mpl_17_jul_02\libs\mpl\test\find.cpp(44) : error C2039:
'is_same_test_dummy' : is not a member of 'integral_c<int,7>'

> > 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).
>
> No it does not. It very simple to setup MS IDE (is it what 
> you are talking about?) so that you will jump with F4 through the list of 
> runtime errors.

Which errors? In my situation (9 different compilers set up as external
tools) the IDE has no knowledge of where the resulting .exe file will
reside, let alone running it and navigating through the results. The fact
that I have to run the test after compiling it is already a pain. Anyway,
it's getting off topic.

The bottom line is that right now I am perfectly satisfied with compile-time
only tests and not going to invest any significant energy into porting them
to unit-test framework for the sole purpose of using one. When there will be
a clear need, I will reconsider.

Aleksey