Re: [Boost-bugs] [Boost C++ Libraries] #6331: [Boost.Test] g++ compilation error due to ambiguity between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if as well as the disable_if counterparts introduced after Boost 1.48.0 (up to at least svn rev. 76217)

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #6331: [Boost.Test] g++ compilation error due to ambiguity between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if as well as the disable_if counterparts introduced after Boost 1.48.0 (up to at least svn rev. 76217)
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-01-18 15:37:43

#6331: [Boost.Test] g++ compilation error due to ambiguity between template<class
Cond, class T> struct boost::enable_if and class
boost::unit_test::decorator::enable_if as well as the disable_if
counterparts introduced after Boost 1.48.0 (up to at least svn rev. 76217)
--------------------------------------+-------------------------------------
  Reporter:  t0rt1e@…                 |       Owner:  rogeeff              
      Type:  Bugs                     |      Status:  new                  
 Milestone:  To Be Determined         |   Component:  test                 
   Version:  Boost Development Trunk  |    Severity:  Regression           
Resolution:                           |    Keywords:  enable_if, disable_if
--------------------------------------+-------------------------------------

Comment (by t0rt1e@…):

 Replying to [comment:3 rogeeff@…]:
 > 1. I am yet to see why this is boost.test fault and not compiler bug.

 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.

 That said, before simply blaming the compiler, we should also make sure
 that it is not some bug in Boost.Test or other Boost component.

 The test case just includes two Boost headers and then fails to compile
 with g++ 4.2.1, 4.5.3, and 4.6.2 (clang+
 + 3.0 compiles just fine 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
 }
 }}}

 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 issuing {{{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.

 > 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. Therefore, I can imaging
 that 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

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/6331#comment:4>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.