Dear Gennadiy, thanks for your response. This is the first response at all that I get on ticket #6331. On Tue, 17 Jan 2012 22:00:37 +0000, Gennadiy Rozental wrote:
Torsten Maehne <Torsten.Maehne <at> gmx.de> writes:
Hello,
concerning regressions in Boost.Test, ticket #6331 "g++ compilation error due to ambiguity between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if
1. I am yet to see why this is boost.test fault and not compiler bug.
Even though, I stumpled on this bug while preparing the test case for ticket #6126, it was Jeroen Habraken <vexocide@gmail.com>, who tracked it down to recent changes in Boost.Test. Did you look at the test case. --------------------------------------------------------------- #define BOOST_TEST_MODULE test_boost_test_decorator_enable_if #include <boost/test/included/unit_test.hpp> #include <boost/typeof/native.hpp> BOOST_AUTO_TEST_CASE(test_dummy) { // do nothing } --------------------------------------------------------------- It just includes two Boost headers and then fails to compile. This enough to make g++ 4.2.1, 4.5.3, and 4.6.2 fail to compile the test case. (clang+ + 3.0 compiles just fine the test case). I'm not familiar enough with all the magic going on behind the scenes in Boost.Test to judge if it not changes the visibility of certain symbols in certain namespaces, e.g., by "using" statements. At least, just including into a test case: --------------------------------------------------------------- #include <boost/test/tree/decorator.hpp> #include <boost/typeof/native.hpp> int main(int argc, char* argv[]) { return 0; } --------------------------------------------------------------- won't cause a compiler error. I don't know what triggers the compiler to look-up enable_if<Cond, T> in the other test case. I don't know either why the compiler sees the definition of boost::unit_test::decorator::enable_if in namespace boost::type_of. I don't know how to further analyse the issue. It's a bit frustrating to see that new tickets in the Boost Trac system seem to receive so few attention compared to other open-source project I have contributed, too. It's good to see that the Boost mailing lists are so much more responsive. :-) It might well be a compiler bug, but seeing how long it takes that new compiler versions are widely deployed even on common platforms such as Windows, Linux, or Mac OS X -- especially in production environments, such issues should be fixed also in the Boost library.
2. I think qualifying symbols from boost namespace is right thing to do in any case
Well, I agree, but what is a user of the Boost libraries able to do about it? Using enable_if and co. without a qualifying namespace is widespread in the Boost sources: A grep on the Boost headers and some filtering shows that enable_if without a qualifying namespace identifier is used approx. 1000 times all over the Boost library. Qualifying all occurences of enable_if and co. will need a quite huge and well coordinated effort to be fixed by the different library authors. I am aware that also other Boost libraries have their own enable_if variants. However, all seem to be templates except for the boost::unit_test::decorator::enable_if. Maybe therefore no problems were yet observed in combination with typename statements. At least that is how far I understand the issue.
3. This code is not part of the release.
This is good to hear. Boost.Test is very useful for me and I use it in conjunction with other Boost libraries regularly. Having it broken in a an official Boost release would cause me quite some headache as suddenly my unit tests for my own code would stop compiling for reasons I cannot influence.
Gennadiy
Best regards, Torsten Maehne