Re: [boost] tr1/test_function_tricky trickier than needed

From: John Maddock (john_at_[hidden])
Date: 2006-07-08 13:33:45

Peter Dimov wrote:
> However, this situation is problematic for several reasons.
>
> * There is code duplication among the tricky and non-tricky tests,
> and this creates a possibility for them to diverge without us
> noticing.

Yep.

> * Someone like me that doesn't pay the necessary attention can
> inadvertently "fix" something that doesn't need fixing.

:-)

> * The current separation of tricky == "100% TR1 compliant",
> non-tricky == "happens to work today" doesn't help us track
> incremental improvements in conformance. For example, consider the
> hypothetical situation in which someone makes changes to bind that
> are supposed to make these tests:
>
>   //BOOST_STATIC_ASSERT(::std::tr1::is_placeholder<T>::value);
>
>
> //BOOST_STATIC_ASSERT(::std::tr1::is_bind_expression<Binder>::value);
>
> pass. This won't be reflected in the test matrix as the non-tricky
> test has them commented and the tricky test will still fail for
> several other
> reasons.

Understood, we need to decide just how many tests to split this up into I 
guess.

> (As an aside, your tricky bind test doesn't test user specializations
> of is_placeholder and is_bind_expression.)
>
> * We need to have a clear idea what is the purpose of the strict
> conformance ("tricky") tests. Do we keep them since we expect that
> these tests will one day pass under the boost implementation? Or do
> we implicitly acknowledge the fact that they will never pass, and
> just keep running them out of principle?
>
> To take bind as an example, I don't expect it ever passing the
> "placeholder as const T&" test because of the header-only nature of
> the implementation
> and real-world precompiled header limitations. So why keep testing
> that? We know that it will fail. (Note that this is a non-rhetorical
> question. There might be a reason, we/I just need to know what it is.)

Don't forget that Boost.TR1 need not be actually using Boost: if there is a 
version of TR1 supplied with the std lib in use then Boost.TR1 can use that 
(actually it *has* to use it if TR1 is in the include path).  In this case 
these tests may well pass: for example quite a few of them do if you enable 
support for the fledgling TR1 implementation in gcc-4.0.x.  Last time I 
looked the gcc TR1 implementation wasn't quite ready to be used as the 
default (so the tests still fail) but I do expect it to become the default 
at some point, at which time the tests should all go green for that 
compiler.

> Finally, we might want to try inserting the following lines:
>
> #if BOOST_FUNCTION_NUM_ARGS == 1
>
>    , public std::unary_function<T0,R>
>
> #elif BOOST_FUNCTION_NUM_ARGS == 2
>
>    , public std::binary_function<T0,T1,R>
>
> #endif
>
> in function_template.hpp:449; this will hopefully allow us to
> dispense with one of the tricky tests. :-)

That would be cool.

Recent fixes to Boost.Array means we can dispense with that one as well I 
believe.

John.