Could you please ping this thread when the fix is available...

To elaborate a bit more:
- Windows *did not* insert or check for the <item_version> tag on collections, while Linux/gcc *does. So I'm guessing that there is some preprocessor switching going on which yields different results across different compilers.

e.g -  if I send a vector<structs> from Linux->Windows the error will occur on the 1st data element in the collection which follows the <item_version> tag for the collection. 

Hope this helps,
Tim


On Mon, Jun 2, 2008 at 5:45 PM, Matthias Troyer <troyer@phys.ethz.ch> wrote:
I have patches for the previously reported problems which I can commit this week. I can't say about the Windows version though.

Matthias


On 2 Jun 2008, at 15:45, Tim St. Clair wrote:

Folks -

I still notice *this error in boost 1.35.0, when transferring data from Linux(gcc 4.1.2) <-> Windows (VS.2005)

Windows<->Windows (fine)
Linux<-> Linux (fine)

Linux will embed <item_version>0</item_version> while windows will not. 
When it attempts to unserialize it will throw a stream error.

Is there an patch for this? 

-Tim




On Fri, Apr 4, 2008 at 1:24 PM, Filip Peters <filippeters@yahoo.com> wrote:


----- Original Message ----
From: "Pfligersdorffer, Christian" <Christian.Pfligersdorffer@eos.info>
To: boost-users@lists.boost.org
Sent: Friday, April 4, 2008 6:30:00 AM
Subject: Re: [Boost-users] serialization, 1.34/1.35 difference: serializing a vector

Hello everybody,

we at EOS too rely heavily on backwards compatibility of
boost::serialization so I read this topic with great interest. And found
Filip's discovery quite shocking I must say!

I tried the testing program on my machine using boost-1.33.1 and
boost-1.35 and all of the boost::archives. And guess what: It worked!!
Soooo, this is quite confusing! Either version 1.34 breaks the
compatibility or Filip's observation is wrong. Or mine, as everything
might depend on the machine architecture or some other nasty detail...
Is think this has to be investigated closer.

Very interesting. I dug up the zip file for 1.33.1 and ran a couple of tests. (mostly to prove myself that I'm not seeing ghosts.)
result:
from 1.33.1 to 1.34: no problem
from 1.33.1 to 1.35: no problem
from 1.34.1 to 1.35: problem.
problem seems to be a new "optimization" in the vector serializing.
I normally use the binary files, but for debugging purposes the xml output is fantastic.
It shows exactly why it works/doesn't work.

xml from 1.33.1:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="3">
<vectorToSave>
    <count>2</count>
    <item>0</item>
    <item>1</item>
</vectorToSave>
</boost_serialization>

xml from 1.34.1:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="4">
<vectorToSave>

    <count>2</count>
    <item_version>0</item_version>
    <item>0</item>
    <item>1</item>
</vectorToSave>
</boost_serialization>

xml from 1.35:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="4">
<vectorToSave>
    <count>2</count>
    <item>0</item>
    <item>1</item>
</vectorToSave>
</boost_serialization>

As you can clearly see, from 1.34.1 to 1.35, the archive version stayed at 4, while item_version went missing in 1.35.



Btw: my portable binary archive which really does nothing more than
endian handling on top of the binary archive was broken by version 1.34
too (wrt reading files generated by 1.33.1). It has to do with the
serialization of std collections as well, that much I found out. I did
not do extensive investigation then but simply did not migrate. I may
have time to take a closer look in the near future though.

Regards,

--
Christian Pfligersdorffer
Software Engineering
http://www.eos.info

PS:

Jens wrote:
> Have you reported these issues? Please remember that once you
> start testing development versions, especially release
> snapshots, you could ensure that such issues are fixed before the
> release!

Never forget that there users who are not so involved in the boost
community, be it for the lack of interest or simply because they are
engaged in projects that leave no room for testing of upcoming library
versions. Between the announcement and the official release there was
less than a laughable day...

Exactly.
I didn't check the boost list in the previous two weeks (busy with an internal release myself), so wasn't really aware that there was rc2 and rc3.(heck, was rc1 even announced on the users list?) Monday I checked and saw that the boost website was updated, and a nice new version.
When I got everything to compile, I noticed that I couldn't read in some older files.
So I made a sample program, and reported the output.
I also opened a trac ticket for this.

Filip Peters.





You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.

_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users



--
Regards,
Timothy St. Clair
[timothysc@gmail.com] _______________________________________________


_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users



--
Regards,
Timothy St. Clair
[timothysc@gmail.com]