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 >> i;
std::cout << "Pos after read: " << is.tellg() << std::endl;
}
std::cout << "Pos after dtor: " << is.tellg() << 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-usBoost C++ Libraries/htdocs/site/boost.png
https://svn.boost.org/trac10/ticket/3447
Trac 1.4.3Robert RameyMon, 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>