[boost] [serialization][msvc-6.5] shared_ptr_132.hpp induces a using-related problem

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2007-09-04 08:31:40

Hello, the following snippet compiles just fine in MSVC++ 6.5:

  #include <boost/tuple/tuple.hpp>

  int main()
  {
    using namespace boost::tuples;
    tuple<int> t(0);
    int x=get<0>(t);
    return 0;
  }

yet the following seemingly innocuous modification:

  #include <boost/tuple/tuple.hpp>
  #include <boost/serialization/shared_ptr_132.hpp>

  int main()
  {
    using namespace boost::tuples;
    tuple<int> t(0);
    int x=get<0>(t);
    return 0;
  }

results in the compiler errors:

  D:\...\tuple_get.cpp(8) : error C2667: 'get' : none of 2 overload have
a best conversion
  D:\...\tuple_get.cpp(8) : error C2668: 'get' : ambiguous call to
overloaded function

The problem is exacerbated in the trunk version of Boost.Serialization
because
a very common header like <boost/archive/text_iarchive.hpp> now
implicitly includes
shared_ptr_132.hpp, thus making the problem described above more likely
to
occur.

  // fails with the trunk version of Boost, not so with Boost 1.34 or
lower
  #include <boost/tuple/tuple.hpp>
  #include <boost/archive/text_iarchive.hpp>

  int main()
  {
    using namespace boost::tuples;
    tuple<int> t(0);
    int x=get<0>(t);
    return 0;
  }

The cause of this problem is yet another bug in namespace dealing by
MSVC++ 6.5 and can be reduced to the following pattern of usage of a
using directive:

  // fails as if <boost/serialization/shared_ptr_132.hpp> were included
  #include <boost/tuple/tuple.hpp>

  namespace boost_132
  {
  using namespace boost;
  }

  namespace boost_132
  {
  }

  int main()
  {
    using namespace boost::tuples;
    tuple<int> t(0);
    int x=get<0>(t);
    return 0;
  }

This pattern is seen in boost/serialization/detail/shared_ptr_132.hpp
and
boost/serialization/detail/shared_count_132.hpp, both implicitly
included
by boost/serialization/shared_ptr_132.hpp.

Admittedly, the problem is somewhat contrived (although it's distilled
from
a real case I found myself) and the offending compiler is not all the
rage
these days :) but I just wanted to report it for the record and in case
the
possibility exists that the problematic using directives can be replaced
by
appropriate using declarations (I don't know if this is feasible.)

Best,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo