Boost C++ Libraries: Ticket #1285: [serialization] problem when including shared_ptr_132.hpp

huangsean@… — Wed, 26 Sep 2007 23:09:18 GMT

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 — Wed, 26 Sep 2007 23:10:00 GMT

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

status changed; resolution set

Robert Ramey — Fri, 30 Nov 2007 05:58:58 GMT

status new → closed
resolution → fixed

try using boost::uint16_t

Robert Ramey

status changed; resolution deleted

huangsean@… — Fri, 30 Nov 2007 21:24:14 GMT

status closed → reopened
resolution fixed

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.

status changed; resolution set

Robert Ramey — Fri, 30 Nov 2007 21:29:46 GMT

status reopened → closed
resolution → wontfix

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.

status changed; resolution deleted

Johan Råde — Wed, 13 Feb 2008 17:33:15 GMT

status closed → reopened
resolution wontfix

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 — Wed, 13 Feb 2008 17:36:22 GMT

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;

status changed; resolution set

Robert Ramey — Fri, 11 Apr 2008 05:11:56 GMT

status reopened → closed
resolution → fixed

fixed - will check in soon

status, severity changed; resolution deleted

Chaker Nakhli (www.javageneration.com) — Tue, 23 Dec 2008 09:48:41 GMT

status closed → reopened
resolution fixed
severity Showstopper → Problem

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.

status changed; resolution set

Robert Ramey — Tue, 30 Dec 2008 19:08:57 GMT

status reopened → closed
resolution → fixed

I think this is fixed in 1.37

Robert Ramey

Chaker Nakhli (www.javageneration.com) — Mon, 05 Jan 2009 16:25:19 GMT

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