From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-11-27 01:23:03
Daryle Walker wrote:
> On 11/26/06 1:42 PM, "Vladimir Prus" <ghost_at_[hidden]> wrote:
>> The test fails on metacomm-v2 for msvc-6.5, 7.0 and for borland:
>> The borland and 6.5 failures seem to be related to compiler problems that
>> trigger *on the test itself*, so it might be possible to revive the test.
>> The 7.0 failures is something deeper inside the math library.
> Borland seems to have a problem requiring explicitly declared
> specialization. I'm not sure that any workaround would be legal on any
> other compiler.
You can wrap the workaround in #ifdef, I think? If that's no feasible, or
there's no workaround, can you mark the failure as expected?
> For MSVC 6.5, the compiler is just fried here. Pure virtual member
> functions look like:
> virtual void my_pure_virtual() = 0;
> Compile-time class-static built-in-integer constants look like:
> static int const my_value = 3;
Yes. Again, if this is not workaroundable, can you mark the failures as
>>From the error messages, it looks like whenever the compiler sees a
> class-static built-in-integer constant that evaluates to zero, it tries
> grouping it as a pure virtual member function, which obviously fails
> the "= 0" is the only thing the two syntaxes have in common. (It seems
> like the creators gave the parser's pure-virtual part too much priority.)
> For MSVC 7.0, it seems like the actual numeric test types aren't correctly
> extracted from the MPL lists (signed_test_types and unsigned_test_types)
> by the various BOOST_AUTO_TEST_CASE_TEMPLATE instances.
So, is this Boost.Test problem, or Boost.Math problem, or test case problem
and what can be done about it?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk