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:
>>
>> http://tinyurl.com/y6otrh
>> http://tinyurl.com/ynz9z3
>> http://tinyurl.com/yxlcv7
>>
>> 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
expected?
>
>>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
> because
> 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?
Thanks,
Volodya