Re: [boost] [math] common_factor_test

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