Boost logo

Boost :

Subject: Re: [boost] Bug reports - Showstoppers and Regressions
From: Torsten Maehne (Torsten.Maehne_at_[hidden])
Date: 2012-01-18 10:20:22

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>> 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_at_[hidden]>, 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>

  // 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

> Gennadiy

Best regards,

Torsten Maehne

Boost list run by bdawes at, gregod at, cpdaniel at, john at