[serialization] problem when including shared_ptr_132.hpp

[huangsean@…]

It seems that the "using namespace ." statements in this and shared_count_132.hpp trigger a problem in VC8 + SP1.

Try the following small program:

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

typedef unsigned short uint16_t;

int main(int argc, char* argv[]) {

uint16_t u;

return 0;

}

Will result in this error:

error C2872: 'uint16_t' : ambiguous symbol

It seems that the workaround implemented for Borland should be extended to VC8 too:

#if !BOOST_WORKAROUND( BORLANDC, BOOST_TESTED_AT( 0x560) ) using namespace boost; #endif

[huangsean@…]

Forgot to mention this only happens with debug build. Release version is OK. I turned off the iterator debuging but that did not fix the problem.

[anonymous]

Please ignore the above comment. It was meant to another defect I submitted

[Robert Ramey]

try using boost::uint16_t

Robert Ramey

[huangsean@…]

Using boost::uint16_t would not be a solution. We have our own uint16_t typedef in our own namespace. Please consider the workaround in my original post. We had to patch our local boost versions that way.

[Robert Ramey]

I'm very disinclined to do such a thing.

you've got your own uint16_t and there as boost one and for all I know and std:

This would resolve the ambiguity in a way that would hide it from other users and create surprising behavior.

[Johan Råde]

Using boost::uint16 instead of uint16_t is not a solution when the problematic uint16_t occurs in some (possible deeply nested) third party header. Especially not when there are third party source files that depend on that header.

Moreover, this problem is just a symptom of a more serious problem. Including the header text_iarchive.hpp with Boost 1.35 and MSVC 7.1 has the effect of dumping the entire content of namespace boost into the global scope. The following example illustrates that:

---

Expected behavior: Should not compile Observed behavior with Boost 1.34.1 and MSVC 7.1: Does not compile Observed behavior with Boost 1.35 and MSVC 7.1: Does compile

#include <boost/shared_ptr.hpp> #include <boost/archive/text_iarchive.hpp> shared_ptr<int> sp;

[anonymous]

The example in my previous post got a bit mangled. Here we go again:

Expected behavior: Should not compile Observed behavior with Boost 1.34.1 and MSVC 7.1: Does not compile Observed behavior with Boost 1.35 and MSVC 7.1: Does compile

#include <boost/shared_ptr.hpp> #include <boost/archive/text_iarchive.hpp> shared_ptr<int> sp;

[Robert Ramey]

fixed - will check in soon

[Chaker Nakhli (www.javageneration.com)]

This problem persists on boost 1.36. For instance, when <boost/archive/text_iarchive.hpp> is included, the symbols shared_ptr<T> and array<T,N> are available in the default namespace. This prevents correct compilation with /clr option on V8.0 SP1. A new ticket was submitted with number #2608.

[Robert Ramey]

I think this is fixed in 1.37

Robert Ramey

[Chaker Nakhli (www.javageneration.com)]

It seems to be OK on 1.37. We had to migrate though (hope the serialization format did not change). Thank you Robert.