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.