https://svn.boost.org/trac10/ticket/3315 <p> The attached code sample demonstrates the issue. If the commented out line in dummy() is reinstated, the deserialization test in main() fails. The behavior is the same for all versions of Boost. </p> <p> A message was posted to Boost Developers mailing list 3 August 2009. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/3315 Trac 1.4.3 Jarl Lindrud <jarl.lindrud@…> Tue, 04 Aug 2009 05:11:32 GMT https://svn.boost.org/trac10/ticket/3315 https://svn.boost.org/trac10/ticket/3315 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">BoostSerializationBug.cpp</span> </li> </ul> Ticket Robert Ramey Tue, 04 Aug 2009 22:14:13 GMT https://svn.boost.org/trac10/ticket/3315#comment:1 https://svn.boost.org/trac10/ticket/3315#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> I've looked into this. When the serialization traits of a type are </p> <p> tracking = track_selectively implemenation_level &lt;= object_serializable </p> <p> No information regarding the type is included in the archive. This is decision based on efficiency considerations. The decision to track is dependent solely upon the code in the program. Thus the side effect of including code even it is not called. Note that default implementation of serialization of collections of primitive types such as vector&lt;char&gt; are setup with these traits. </p> <p> So this behavior is by design. Whether or not this is a good design decision would be a different discussion. I wouldn't change it now since it would likely break a lot of archives "out there" </p> <p> I did include a BOOST_STATIC_WARNING if one attempts to save a pointer to such a type. Doing this would be unusual and could result and archive which might be unreadable. </p> Ticket