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<http://us.rd.yahoo.com/evt=47523/*http://tc.deals.yahoo.com/tc/blockbuster/text5.com>, 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
_______________________________________________ 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]