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.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:08 UTC