From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-07-08 12:17:38
John Maddock wrote:
> Peter Dimov wrote:
>>> The only difference between this test and the "non-tricky" one is
>>> the presence of those two lines. The test is intentionally
>> It didn't occur to me to look at the non-tricky test. :-)
>> Why did you decide to duplicate all non-tricky portions in the tricky
>> as well? We are running both.
> Well originally they weren't supposed to be tricky: there was
> supposed to be one test that "concept checked" each TR1 section, when
> I found that Boost didn't support a few of the features, I just
> commented out those parts that Boost didn't support and made these
> the "non-tricky" tests, and the "complete" unmolested versions became
> the "tricky" tests.
Ah, I see. Thanks for the explanation. This means that my patch to
test_bind_tricky has been completely misguided, sorry about that. Feel free
to revert it.
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:
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
(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.)
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>
in function_template.hpp:449; this will hopefully allow us to dispense with
one of the tricky tests. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk