Daryle Walker wrote:
On 11/26/06 1:42 PM, "Vladimir Prus" <ghost@cs.msu.su> 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