Re: [Boost-users] serialization, 1.34/1.35 difference: serializing a vector
Huh? I just got the whole trunk, and built it. Still the same problem: it can't read in std::vector<int> created with 1.34.1 Anyway how would a fix in trunk help? -I can't use the released version 1.35, as it can't read in older files. -I can't use trunk in our program, only released/tested versions. I just tried compiling with trunk, seems there are some other issues in other libraries that would take some work. (something went missing in the signals library) Yes, I can add item_version into the optimised versions of vector.hpp, but how is it going to work in 1.36? If you'd tell how you would fix it in the 1.35 version, I could use just that fix in our version, untill 1.35.1 or 1.36 comes out. Without ending up with our own branched version that's always incompatible with the released versions. thanks, Filip Peters ----- Original Message ---- From: Robert Ramey <ramey@rrsd.com> To: boost-users@lists.boost.org Sent: Thursday, April 3, 2008 8:32:52 AM Subject: Re: [Boost-users] serialization, 1.34/1.35 difference: serializing a vector Looks like the trunk version is already fixed. Robert Ramey "Filip Peters" <filippeters@yahoo.com> wrote in message news:753101.4971.qm@web30701.mail.mud.yahoo.com... I looked a bit deeper into the code and found this: in 1.34.1, a vector would use the code from collections_save_imp.hpp, which contains the following: unsigned int count = s.size(); ar << BOOST_SERIALIZATION_NVP(count); if(3 < ar.get_library_version()){ const unsigned int item_version = version< BOOST_DEDUCED_TYPENAME Container::value_type >::value; ar << BOOST_SERIALIZATION_NVP(item_version); } in 1.35.0, there is an "optimized" version in vector.hpp, const collection_size_type count(t.size()); ar << BOOST_SERIALIZATION_NVP(count); if (!t.empty()) ar << make_array(detail::get_data(t),t.size()); without the item_version. Loading a vector of a type like int or double, created in 1.34 won't work in 1.35. Filip Peters. Haven't used boost's trac before, but I'll enter it tomorrow. In the meantime, adding item_version into the optimized versions seems to solve my problem, except I have to make sure it doesn't break in the next version. ----- Original Message ---- From: Robert Ramey <ramey@rrsd.com> To: boost-users@lists.boost.org Sent: Wednesday, April 2, 2008 6:30:01 PM Subject: Re: [Boost-users] serialization, 1.34/1.35 difference: serializing a vector Hmm I don't recal where that might have come from. Open a TRAK item. Robert Ramey "Filip Peters" <filippeters@yahoo.com> wrote in message news:859190.51711.qm@web30705.mail.mud.yahoo.com... I just tried serializing a simple vector, std::vector<unsigned int> vectortest; If I serialize out in 1.34, I can't read it in in 1.35. xml result from 1.35: <vectortest> <count>3</count> <item>1</item> <item>2</item> <item>3< /item> </vectortest> from 1.34: <vectortest> <count>3</count> <item_version>0</item_version> <item>1</item> &n bsp; <item>2</item> <item>3</item> </vectortest> Notice the item_version, this causes an exception when reading it in with 1.35.... I need a way to get the behavior from 1.34 back.... Otherwise my files aren't readable anymore. small testprogram: #include <boost/config.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> //#include <boost/archive/binary_iarchive.hpp> //#include <boost/archive/binary_oarchive.hpp> #include <boost/serialization/vector.hpp> #include <boost/serialization/export.hpp> #include <fstream> #include <iomanip> int _tmain(int argc, _TCHAR* argv[]) { std::vector<unsigned int> testvector; testvector.push_back(1.); testvector.push_back (2.); testvector.push_back(3.); //this in 1.34 std::ofstream ofs( "testing2.txt", std::ios::binary ) ; boost::archive::xml_oarchive oa(ofs); oa << boost::serialization::make_nvp("vectortest", testvector); ofs.close(); //do this in 1.35 try{ std::ifstream ofs( "testing2.txt", std::ios::binary ) ; boost::archive::xml_iarchive ia(ofs); ia >> boost::serialization::make_nvp("vectortest", testvector2); &nb sp; ofs.close(); } catch(boost::archi ve::archive_exception testexception){ //reading a file from 1.34, will end up here std::string error = testexception.what(); } return 0; } ____________________________________________________________________________________ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com
On Thu, Apr 3, 2008 at 4:09 PM, Filip Peters <filippeters@yahoo.com> wrote:
Huh? I just got the whole trunk, and built it. Still the same problem: it can't read in std::vector<int> created with 1.34.1
Anyway how would a fix in trunk help? -I can't use the released version 1.35, as it can't read in older files. -I can't use trunk in our program, only released/tested versions. I just tried compiling with trunk, seems there are some other issues in other libraries that would take some work. (something went missing in the signals library)
Maybe we should start thinking about a 1.35.1 version? archive compatibility is a serious problem IMHO.
Yes, I can add item_version into the optimised versions of vector.hpp, but how is it going to work in 1.36? If you'd tell how you would fix it in the 1.35 version, I could use just that fix in our version, untill 1.35.1 or 1.36 comes out. Without ending up with our own branched version that's always incompatible with the released versions.
thanks, Filip Peters
[snip] -- Felipe Magno de Almeida
On Thu, Apr 03, 2008 at 12:09:27PM -0700, Filip Peters wrote:
Huh? I just got the whole trunk, and built it. Still the same problem: it can't read in std::vector<int> created with 1.34.1
Anyway how would a fix in trunk help? -I can't use the released version 1.35, as it can't read in older files.
Right, this wouldn't help.
-I can't use trunk in our program, only released/tested versions. I just tried
You mean it is your policy, right?
compiling with trunk, seems there are some other issues in other libraries that would take some work. (something went missing in the signals library)
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! Now imagine the serialisation issues will be fixed but you would still fail to compile signals, it would not nice for you too, right? I'm not sure but I think that even trunk code should *always* compile cleanly. There may of course be problems with non conforming compilers which are found later ...
If you'd tell how you would fix it in the 1.35 version, I could use just that fix in our version, untill 1.35.1 or 1.36 comes out. Without ending up with our own branched version that's always incompatible with the released versions.
You could indeed add a local copy of boost to your source code. So you would be on the save side. This is especially an option as Boost guarantees no fixed API and ABI.
----- Original Message ---- From: Robert Ramey <ramey@rrsd.com>
Please learn properly quoting and avoid top postings! Jens
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. 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...
participants (1)
-
Felipe Magno de Almeida -
Filip Peters -
Jens Seidel -
Pfligersdorffer, Christian