[rational][operators] VC6/7 supported? (Trying to clear regressions)
What's the state of support for VC6/7 in Boost.Operators? I'm asking because I started investigating the remaining regressions for Boost.Rational and I've come up against a road-block: I can get everything to work (at least I think so), but not the comparison operators, so: my_rational_1 != my_rational_2 doesn't compile with VC6/7, but does with everything else. I'm assuming that's because these compilers don't find the necessary friend-functions in the operators base classes, or is there something else going on here? The error message is: rational_test.cpp(261) : error C2678: binary '!=' : no operator defined which takes a left-hand operand of type 'class boost::rational<short>' (or there is no acceptable conversion) ../../boost/test/test_case_template.hpp(73) : while compiling class-template member function 'void __thiscall basic_rational_suite::rational_comparison_test<short>::test_method(void)' BTW is the use of Boost.Operators by the rational lib new to this version? If so we might just have to mark up VC6/7 as unsupported. Thanks, John.
John Maddock <john <at> johnmaddock.co.uk> writes:
What's the state of support for VC6/7 in Boost.Operators?
I'm asking because I started investigating the remaining regressions for Boost.Rational and I've come up against a road-block: I can get everything to work (at least I think so), but not the comparison operators, so:
my_rational_1 != my_rational_2
doesn't compile with VC6/7, but does with everything else. I'm assuming that's because these compilers don't find the necessary friend-functions in the operators base classes, or is there something else going on here?
I think this is a testing artifact. The following compiles and works just fine in VC 6.5: #include <boost/rational.hpp> int main() { boost::rational<short> r1,r2; r1!=r2; return 0; }
BTW is the use of Boost.Operators by the rational lib new to this version?
No, the lib is basically unchanged since 1.30, the only significant modification has been the addition of a boolean conversion operator, which is immaterial to this issue (same problems even if I remove it.) What's new about 1.33 wrt 1.32 is the refactoring of rational_test.cpp to use Boost.Test instead of the old homegrown test framework. This is probably hitting some VC6.5/7.0 bug --in particular, my hunches are related to the kind of bugs BOOST_EXPLICIT_TEMPLATE_TYPE is designed to solve.
If so we might just have to mark up VC6/7 as unsupported.
Let me try my hand at it first, I think I'll be able to make it work in a few days.
Thanks,
John.
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquin M Lopez Munoz wrote:
Let me try my hand at it first, I think I'll be able to make it work in a few days.
Thanks Joaquin: in the mean time you might like to know that most of the currect errors are down to problems with using declarations and those compilers, here are my current patches that I think gets everything except those non-member operators working. John. Index: libs/rational/rational_test.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/rational/rational_test.cpp,v retrieving revision 1.19 diff -u -r1.19 rational_test.cpp --- libs/rational/rational_test.cpp 5 Jan 2006 13:31:24 -0000 1.19 +++ libs/rational/rational_test.cpp 18 Oct 2006 08:53:48 -0000 @@ -164,41 +164,37 @@ // GCD tests BOOST_AUTO_TEST_CASE_TEMPLATE( gcd_test, T, all_signed_test_types ) { - using boost::gcd; - - BOOST_CHECK_EQUAL( gcd<T>( 1, -1), static_cast<T>( 1) ); - BOOST_CHECK_EQUAL( gcd<T>( -1, 1), static_cast<T>( 1) ); - BOOST_CHECK_EQUAL( gcd<T>( 1, 1), static_cast<T>( 1) ); - BOOST_CHECK_EQUAL( gcd<T>( -1, -1), static_cast<T>( 1) ); - BOOST_CHECK_EQUAL( gcd<T>( 0, 0), static_cast<T>( 0) ); - BOOST_CHECK_EQUAL( gcd<T>( 7, 0), static_cast<T>( 7) ); - BOOST_CHECK_EQUAL( gcd<T>( 0, 9), static_cast<T>( 9) ); - BOOST_CHECK_EQUAL( gcd<T>( -7, 0), static_cast<T>( 7) ); - BOOST_CHECK_EQUAL( gcd<T>( 0, -9), static_cast<T>( 9) ); - BOOST_CHECK_EQUAL( gcd<T>( 42, 30), static_cast<T>( 6) ); - BOOST_CHECK_EQUAL( gcd<T>( 6, -9), static_cast<T>( 3) ); - BOOST_CHECK_EQUAL( gcd<T>(-10, -10), static_cast<T>(10) ); - BOOST_CHECK_EQUAL( gcd<T>(-25, -10), static_cast<T>( 5) ); + BOOST_CHECK_EQUAL( boost::gcd<T>( 1, -1), static_cast<T>( 1) ); + BOOST_CHECK_EQUAL( boost::gcd<T>( -1, 1), static_cast<T>( 1) ); + BOOST_CHECK_EQUAL( boost::gcd<T>( 1, 1), static_cast<T>( 1) ); + BOOST_CHECK_EQUAL( boost::gcd<T>( -1, -1), static_cast<T>( 1) ); + BOOST_CHECK_EQUAL( boost::gcd<T>( 0, 0), static_cast<T>( 0) ); + BOOST_CHECK_EQUAL( boost::gcd<T>( 7, 0), static_cast<T>( 7) ); + BOOST_CHECK_EQUAL( boost::gcd<T>( 0, 9), static_cast<T>( 9) ); + BOOST_CHECK_EQUAL( boost::gcd<T>( -7, 0), static_cast<T>( 7) ); + BOOST_CHECK_EQUAL( boost::gcd<T>( 0, -9), static_cast<T>( 9) ); + BOOST_CHECK_EQUAL( boost::gcd<T>( 42, 30), static_cast<T>( 6) ); + BOOST_CHECK_EQUAL( boost::gcd<T>( 6, -9), static_cast<T>( 3) ); + BOOST_CHECK_EQUAL( boost::gcd<T>(-10, -10), static_cast<T>(10) ); + BOOST_CHECK_EQUAL( boost::gcd<T>(-25, -10), static_cast<T>( 5) ); } // LCM tests BOOST_AUTO_TEST_CASE_TEMPLATE( lcm_test, T, all_signed_test_types ) { - using boost::lcm; - - BOOST_CHECK_EQUAL( lcm<T>( 1, -1), static_cast<T>( 1) ); - BOOST_CHECK_EQUAL( lcm<T>( -1, 1), static_cast<T>( 1) ); - BOOST_CHECK_EQUAL( lcm<T>( 1, 1), static_cast<T>( 1) ); - BOOST_CHECK_EQUAL( lcm<T>( -1, -1), static_cast<T>( 1) ); - BOOST_CHECK_EQUAL( lcm<T>( 0, 0), static_cast<T>( 0) ); - BOOST_CHECK_EQUAL( lcm<T>( 6, 0), static_cast<T>( 0) ); - BOOST_CHECK_EQUAL( lcm<T>( 0, 7), static_cast<T>( 0) ); - BOOST_CHECK_EQUAL( lcm<T>( -5, 0), static_cast<T>( 0) ); - BOOST_CHECK_EQUAL( lcm<T>( 0, -4), static_cast<T>( 0) ); - BOOST_CHECK_EQUAL( lcm<T>( 18, 30), static_cast<T>(90) ); - BOOST_CHECK_EQUAL( lcm<T>( -6, 9), static_cast<T>(18) ); - BOOST_CHECK_EQUAL( lcm<T>(-10, -10), static_cast<T>(10) ); - BOOST_CHECK_EQUAL( lcm<T>( 25, -10), static_cast<T>(50) ); + BOOST_CHECK_EQUAL( boost::lcm<T>( 1, -1), static_cast<T>( 1) ); + BOOST_CHECK_EQUAL( boost::lcm<T>( -1, 1), static_cast<T>( 1) ); + BOOST_CHECK_EQUAL( boost::lcm<T>( 1, 1), static_cast<T>( 1) ); + BOOST_CHECK_EQUAL( boost::lcm<T>( -1, -1), static_cast<T>( 1) ); + BOOST_CHECK_EQUAL( boost::lcm<T>( 0, 0), static_cast<T>( 0) ); + BOOST_CHECK_EQUAL( boost::lcm<T>( 6, 0), static_cast<T>( 0) ); + BOOST_CHECK_EQUAL( boost::lcm<T>( 0, 7), static_cast<T>( 0) ); + BOOST_CHECK_EQUAL( boost::lcm<T>( -5, 0), static_cast<T>( 0) ); + BOOST_CHECK_EQUAL( boost::lcm<T>( 0, -4), static_cast<T>( 0) ); + BOOST_CHECK_EQUAL( boost::lcm<T>( 18, 30), static_cast<T>(90) ); + BOOST_CHECK_EQUAL( boost::lcm<T>( -6, 9), static_cast<T>(18) ); + BOOST_CHECK_EQUAL( boost::lcm<T>(-10, -10), static_cast<T>(10) ); + BOOST_CHECK_EQUAL( boost::lcm<T>( 25, -10), static_cast<T>(50) ); } BOOST_AUTO_TEST_SUITE_END() @@ -569,17 +565,15 @@ // Conversion test BOOST_AUTO_TEST_CASE( rational_cast_test ) { - using boost::rational_cast; - // Note that these are not generic. The problem is that rational_cast<T> // requires a conversion from IntType to T. However, for a user-defined // IntType, it is not possible to define such a conversion except as an // "operator T()". This causes problems with overloading resolution. boost::rational<int> const half( 1, 2 ); - BOOST_CHECK_CLOSE( rational_cast<double>(half), 0.5, 0.01 ); - BOOST_CHECK_EQUAL( rational_cast<int>(half), 0 ); - BOOST_CHECK_EQUAL( rational_cast<MyInt>(half), MyInt() ); + BOOST_CHECK_CLOSE( boost::rational_cast<double>(half), 0.5, 0.01 ); + BOOST_CHECK_EQUAL( boost::rational_cast<int>(half), 0 ); + BOOST_CHECK_EQUAL( boost::rational_cast<MyInt>(half), MyInt() ); } // Dice tests (a non-main test) diff -u -r1.16 rational.hpp --- boost/rational.hpp 27 Dec 2005 11:38:27 -0000 1.16 +++ boost/rational.hpp 18 Oct 2006 08:55:54 -0000 @@ -508,7 +508,7 @@ // Type conversion template <typename T, typename IntType> -inline T rational_cast(const rational<IntType>& src) +inline T rational_cast(const rational<IntType>& src BOOST_APPEND_EXPLICIT_TEMPL ATE_TYPE(T)) { return static_cast<T>(src.numerator())/src.denominator(); }
John Maddock ha escrito:
Joaquin M Lopez Munoz wrote:
Let me try my hand at it first, I think I'll be able to make it work in a few days.
Thanks Joaquin: in the mean time you might like to know that most of the currect errors are down to problems with using declarations and those compilers, here are my current patches that I think gets everything except those non-member operators working.
Well, I think I've got it. After applying your patch, the remaining issues were: * MSVC 6.5/7.0 needs that the various rational<T> types involved be explicitly instantiated vg as follows: ::boost::rational<short> dummy1; ::boost::rational<int> dummy2; ::boost::rational<long> dummy3; ::boost::rational<MyInt> dummy4; in order to fully generate the associated friend operators. This is not the first time I see this behavior, seems like the compiler has problems with Barton-Nackman injected operators when the associated type is instantiated only inside template code. * Old compilers like MSVC 6.5/7.0, BCB and CW 8.2 seem to have problems with brace-enclosed initializer lists for an aggregate type at line 130. The simple solution is to do the initialization by hand. With these changes things go smooth with MSVC 6.5. I can't try MSVC 7.0, BCB and CW 8.3 but I'm quite confident these will be cleared also. This will leave us with Sun 5.8, about which I don't have any clue. Could you sanity check the attached files? If no objection is raised I can commit later this afternoon Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
John Maddock ha escrito:
Joaquin M Lopez Munoz wrote:
Let me try my hand at it first, I think I'll be able to make it work in a few days.
Thanks Joaquin: in the mean time you might like to know that most of the currect errors are down to problems with using declarations and those compilers, here are my current patches that I think gets everything except those non-member operators working.
Well, I think I've got it. After applying your patch, the remaining issues were:
* MSVC 6.5/7.0 needs that the various rational<T> types involved be explicitly instantiated vg as follows:
boost::rational<short> dummy1; boost::rational<int> dummy2; boost::rational<long> dummy3; boost::rational<MyInt> dummy4;
in order to fully generate the associated friend operators. This is not the first time I see this behavior, seems like the compiler has problems with Barton-Nackman injected operators when the associated type is instantiated only inside template code.
* Old compilers like MSVC 6.5/7.0, BCB and CW 8.2 seem to have problems with brace-enclosed initializer lists for an aggregate type at line 130. The simple solution is to do the initialization by hand.
With these changes things go smooth with MSVC 6.5. I can't try MSVC 7.0, BCB and CW 8.3 but I'm quite confident these will be cleared also. This will leave us with Sun 5.8, about which I don't have any clue.
Could you sanity check the attached files? If no objection is raised I can commit later this afternoon
I've tested with VC-6, 7 and 7.1 and with Borland 5.6.4 and 5.8.2 and they all pass now, so yes please do commit. Thanks, John.
2006/10/18, John Maddock <john@johnmaddock.co.uk>:
Joaquín Mª López Muñoz wrote:
With these changes things go smooth with MSVC 6.5. I can't try MSVC 7.0, BCB and CW 8.3 but I'm quite confident these will be cleared also. This will leave us with Sun 5.8, about which I don't have any clue.
Could you sanity check the attached files? If no objection is raised I can commit later this afternoon
I've tested with VC-6, 7 and 7.1 and with Borland 5.6.4 and 5.8.2 and they all pass now, so yes please do commit.
John, could you please describe the problem with Sun 5.8? -- Simon Atanasyan
Simon Atanasyan ha escrito:
2006/10/18, John Maddock <john@johnmaddock.co.uk>:
Joaquín Mª López Muñoz wrote:
With these changes things go smooth with MSVC 6.5. I can't try MSVC 7.0, BCB and CW 8.3 but I'm quite confident these will be cleared also. This will leave us with Sun 5.8, about which I don't have any clue.
Could you sanity check the attached files? If no objection is raised I can commit later this afternoon
I've tested with VC-6, 7 and 7.1 and with Borland 5.6.4 and 5.8.2 and they all pass now, so yes please do commit.
John, could you please describe the problem with Sun 5.8?
The error message can be consulted at http://tinyurl.com/yyudmt You might want to wait for the next cycle a few hours, since the current result is older than the fixes commited yeterday and it's possible that things have changed as a result. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
2006/10/19, Joaquín Mª López Muñoz <joaquin@tid.es>:
The error message can be consulted at
You might want to wait for the next cycle a few hours, since the current result is older than the fixes commited yeterday and it's possible that things have changed as a result.
Good thing - the development version of Sun C++ does not contain this bug. Bad thing - Sun Studio 11 with the latest patch still contains this bug. I try to estimate can we fix this bug in the Sun Studio 11. -- Simon Atanasyan
Simon Atanasyan ha escrito:
2006/10/19, Joaquín Mª López Muñoz <joaquin@tid.es>:
The error message can be consulted at
You might want to wait for the next cycle a few hours, since the current result is older than the fixes commited yeterday and it's possible that things have changed as a result.
Good thing - the development version of Sun C++ does not contain this bug. Bad thing - Sun Studio 11 with the latest patch still contains this bug. I try to estimate can we fix this bug in the Sun Studio 11.
Hello Simon, Could you please provide me with a description of the bug i.e. why Sun Studio 11 can't cope with the code at rational_test.cpp? I can use your description to mark this as expected failure (for the moment being, given that we're trying to get the release out asap) and add an explanatory note.
Simon Atanasyan
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
2006/10/19, Joaquín Mª López Muñoz <joaquin@tid.es>:
Simon Atanasyan ha escrito:
2006/10/19, Joaquín Mª López Muñoz <joaquin@tid.es>:
The error message can be consulted at
You might want to wait for the next cycle a few hours, since the current result is older than the fixes commited yeterday and it's possible that things have changed as a result.
Good thing - the development version of Sun C++ does not contain this bug. Bad thing - Sun Studio 11 with the latest patch still contains this bug. I try to estimate can we fix this bug in the Sun Studio 11.
Hello Simon,
Could you please provide me with a description of the bug i.e. why Sun Studio 11 can't cope with the code at rational_test.cpp? I can use your description to mark this as expected failure (for the moment being, given that we're trying to get the release out asap) and add an explanatory note.
The overload resolution error occurs if: 1. some class has user-defined conversion to the reference to a plain type, and 2. there is oveloading between a user-def operator and built-in one, and 3. The built-in operator takes the result of the conversion mentioned in 1 as an operand. I've just met with sustaining team. This fix has been backported to Studio 11 and will be included in the next patch (number 6). -- Simon Atanasyan
Simon Atanasyan ha escrito:
2006/10/19, Joaquín Mª López Muñoz <joaquin@tid.es>:
Simon Atanasyan ha escrito:
2006/10/19, Joaquín Mª López Muñoz <joaquin@tid.es>:
The error message can be consulted at
You might want to wait for the next cycle a few hours, since the current result is older than the fixes commited yeterday and it's possible that things have changed as a result.
Good thing - the development version of Sun C++ does not contain this bug. Bad thing - Sun Studio 11 with the latest patch still contains this bug. I try to estimate can we fix this bug in the Sun Studio 11.
Hello Simon,
Could you please provide me with a description of the bug i.e. why Sun Studio 11 can't cope with the code at rational_test.cpp? I can use your description to mark this as expected failure (for the moment being, given that we're trying to get the release out asap) and add an explanatory note.
The overload resolution error occurs if: 1. some class has user-defined conversion to the reference to a plain type, and 2. there is oveloading between a user-def operator and built-in one, and 3. The built-in operator takes the result of the conversion mentioned in 1 as an operand.
I've just met with sustaining team. This fix has been backported to Studio 11 and will be included in the next patch (number 6).
Thanks for the explanation! I just included your explanation in a associated expected failure entry, will remove it once the next patch arrives. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Simon Atanasyan wrote:
Good thing - the development version of Sun C++ does not contain this bug. Bad thing - Sun Studio 11 with the latest patch still contains this bug. I try to estimate can we fix this bug in the Sun Studio 11.
Thanks for information, while we have your attention, can we persuade you to take a look at http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/is... and scan down for the Sun-5.8 failures? There are a few that are showing internal signals in the compiler, if you can give us an idea of which if any may be fixable, and which we should just shrug and move on over, that would be a big help. Many thanks! John Maddock.
2006/10/19, John Maddock <john@johnmaddock.co.uk>:
Thanks for information, while we have your attention, can we persuade you to take a look at http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/is... and scan down for the Sun-5.8 failures?
There are a few that are showing internal signals in the compiler, if you can give us an idea of which if any may be fixable, and which we should just shrug and move on over, that would be a big help.
rational/rational_test Fixed in the next patch (06) spirit/mix_and_match_trees Known bug. Just change "typedef rule<Scanner> rule" to "typedef rule<Scanner> rule_" parameter/python_test I cannot say anything because I don't have installed Python. filesystem/mbcopy filesystem/wide_test mpl/vector_c Fixed in the development branch. parameter/preprocessor_deduced parameter/optional_deduced_sfinae Bugs have not beed fixed yet. I need a time to investigate is it possible to create workaround for these bugs. -- Simon Atanasyan
Simon Atanasyan wrote:
filesystem/mbcopy filesystem/wide_test mpl/vector_c Fixed in the development branch.
Sorry for being dense: our development branch (cvs HEAD), or your compilers? If the latter, I'll mark these as expected failures for now. Many thanks, John.
2006/10/19, John Maddock <john@johnmaddock.co.uk>:
Simon Atanasyan wrote:
filesystem/mbcopy filesystem/wide_test mpl/vector_c Fixed in the development branch.
Sorry for being dense: our development branch (cvs HEAD), or your compilers? If the latter, I'll mark these as expected failures for now.
It's my mistake - I mean compiler development branch. -- Simon Atanasyan
Simon Atanasyan skrev:
2006/10/19, John Maddock <john@johnmaddock.co.uk>:
Thanks for information, while we have your attention, can we persuade you to take a look at http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/is... and scan down for the Sun-5.8 failures?
There are a few that are showing internal signals in the compiler, if you can give us an idea of which if any may be fixable, and which we should just shrug and move on over, that would be a big help.
rational/rational_test Fixed in the next patch (06)
spirit/mix_and_match_trees Known bug. Just change "typedef rule<Scanner> rule" to "typedef rule<Scanner> rule_"
parameter/python_test I cannot say anything because I don't have installed Python.
filesystem/mbcopy filesystem/wide_test mpl/vector_c Fixed in the development branch.
parameter/preprocessor_deduced parameter/optional_deduced_sfinae Bugs have not beed fixed yet.
I need a time to investigate is it possible to create workaround for these bugs.
Douglas Gregor, is the contact on the OSL4-V2 sun-5.8 tests. But I fire off a question here: Is there a rationale following the decision to mark some of the libraries in boost as N/A for this compiler? This seems to apply to ublas, phyton, statechart and expressive. Does this mean they have never been tested? Or are they deemed hopeless? Or simply not run for whatever other reasons? I would also like to hear Simon Atanasyan's perspective on compatibility with these libraries. Are there any known issues? As a user of this compiler and boost for many years now, it is exciting to notice how quickly Sun recently has been closing in on boost compliance. --- Bjorn Roald
Simon Atanasyan wrote:
rational/rational_test Fixed in the next patch (06)
spirit/mix_and_match_trees Known bug. Just change "typedef rule<Scanner> rule" to "typedef rule<Scanner> rule_"
parameter/python_test I cannot say anything because I don't have installed Python.
filesystem/mbcopy filesystem/wide_test mpl/vector_c Fixed in the development branch.
parameter/preprocessor_deduced parameter/optional_deduced_sfinae Bugs have not beed fixed yet.
I need a time to investigate is it possible to create workaround for these bugs.
Thanks for the information Simon, that's very useful and I've marked these up accordingly. Thanks, John.
participants (5)
-
Bjørn Roald -
Joaquin M Lopez Munoz -
Joaquín Mª López Muñoz
-
John Maddock -
Simon Atanasyan