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
----- Original Message ---- From: "Pfligersdorffer, Christian"
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>
<vectorToSave> <count>2</count> <item>0</item> <item>1</item> </vectorToSave> xml from 1.34.1: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization>
<vectorToSave> <count>2</count> 0 <item>0</item> <item>1</item> </vectorToSave>xml from 1.35: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization>
<vectorToSave> <count>2</count> <item>0</item> <item>1</item> </vectorToSave> 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 Accesshttp://us.rd.yahoo.com/evt=47523/*http://tc.deals.yahoo.com/tc/blockbuster/t..., 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]