From: David Abrahams (dave_at_[hidden])
Date: 2007-01-14 13:00:41
* I just want to point out up front that the discussion below is
* irrelevant to the question of whether failure markup and its
* processing is broken or not
Roland Schwarz <roland.schwarz_at_[hidden]> writes:
> David Abrahams wrote:
>> Douglas Gregor <dgregor_at_[hidden]> writes:
>>> class_concept_fail_expected: borland-5.6.4 borland-5.8.2 borland-5.8.2 msvc-6.5 msvc-6.5 msvc-7.0
>>> stl_concept_covering: borland-5.8.2 borland-5.8.2 gcc-3.3.6 gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc
>> Jeremy Siek checked in expected failures markup for all these tests
>> well over one week ago. The markup looks OK to me, but the
>> failures are still showing up. What's going on here?
> I don't think marking them as expected to fail on all platforms is
> the way to go.
He didn't do that for class_concept_fail_expected. For
stl_concept_covering it's at least more appropriate than leaving them
unmarked. Since it's mostly a test of the standard library they
should probably be removed from the Boost suite, but that's another
> I looked into the one that seemingly is causing one of the
> stl_concept_covering tests:
> #if defined(__GNUC__)
> typedef less_than_op_first_archetype<> FT;
> typedef less_than_op_second_archetype<> T;
> #elif defined(__KCC)
> // The KAI version of this uses a one-argument less-than function
> // object.
> typedef less_than_comparable_archetype<> T;
> typedef convertible_to_archetype<T> FT;
> forward_iterator_archetype<FT> fi;
> T value(dummy_cons);
> fi = std::lower_bound(fi, fi, value);
> This looks very strange to me.
> Only __GNUC__ or __KCC ever will be able to pass. What about other
> compilers, or nothing of both defined? Why not simply disable the
> test in these cases?
Isn't that just one of many parts of this test that are broken on most
toolsets? IIRC that's the case. Jeremy?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk