Boost C++ Libraries: Ticket #3447: After destruction binary_iarchive seeks to the end of file https://svn.boost.org/trac10/ticket/3447 <p> After destruction binary_iarchive seeks to the end of file. This is occured because boost::archive::basic_binary_iprimitive (the ancestor of binary_iarchive) calls std::basic_streambuf::sync in destructor. Calling 'sync' on a file streambuf seeks to the end of file. </p> <p> This is bad, because it lead to skipping of unread input data! </p> <p> I think calling 'sync' is a bad idea (and this call should be removed), but if it is necessary, then the documentation must clearly note that using a file streambuf with binary_iarchive skips to the end of the file. </p> <hr /> <p> Example: </p> <pre class="wiki">std::ifstream is( ARCHIVE_FILE_NAME, std::ios::binary ); int i; { boost::archive::binary_iarchive ar( is, boost::archive::no_header ); ar &gt;&gt; i; std::cout &lt;&lt; "Pos after read: " &lt;&lt; is.tellg() &lt;&lt; std::endl; } std::cout &lt;&lt; "Pos after dtor: " &lt;&lt; is.tellg() &lt;&lt; std::endl; </pre><p> Output: </p> <pre class="wiki">Pos after read: 4 Pos after dtor: 11 </pre><p> (sizeof(int) is 4, archive file length is 11) </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/3447 Trac 1.4.3 Robert Ramey Mon, 14 Sep 2009 19:27:35 GMT <link>https://svn.boost.org/trac10/ticket/3447#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/3447#comment:1</guid> <description> <p> Note that it has always been my idea that serialized data could be embedded into another stream. I think the question you've raised touches upon this. </p> <p> note the comment at line # 174 of basic_binary_iprimitive.hpp </p> <p> <em> some libraries including stl and libcomo fail if the </em> buffer isn't flushed before the code_cvt facet is changed. <em> I think this is a bug. We explicity invoke sync to when </em> we're done with the streambuf to work around this problem. <em> Note that sync is a protected member of stream buff so we </em> have to invoke it through a contrived derived class. </p> <p> this suggests that the "sync" was only added in response to some other difficulty. Take another look at this problem and tell me what you think. </p> <p> Robert Ramey </p> </description> <category>Ticket</category> </item> </channel> </rss>