Boost logo

Boost :

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.


> * 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

> (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

> Finally, we might want to try inserting the following lines:
> , public std::unary_function<T0,R>
> , 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


Boost list run by bdawes at, gregod at, cpdaniel at, john at