[serialization, archive] Serialize boost::shared_ptr to custom archive
Hi, I'm trying to serialize a boost::shared_ptr to a custom archive. The compiler complains about the archive missing methods 'append' and 'reset'. Does anyone know where I should look to find out more information about these two methods? I wasn't able to find any documentation when looking at the Archive Concept about these two methods, and text_iarchive, together with its base classes, don't seem to declare it. On the other hand, boost::archive::text_iarchive compiles fine. Here are the compile errors I see: /usr/include/boost/serialization/shared_ptr.hpp:133:9: error: ‘class my_iarchive’ has no member named ‘append’ /usr/include/boost/serialization/shared_ptr.hpp:139:5: error: ‘class my_iarchive’ has no member named ‘reset’ My boost version is 1.46 (which comes with openSuse 12.1) Thank you in advance.
Am 10.03.2013 01:27, schrieb Silviu P:
Hi,
I'm trying to serialize a boost::shared_ptr to a custom archive. The compiler complains about the archive missing methods 'append' and 'reset'. Does anyone know where I should look to find out more information about these two methods?
Derive your archive class from detail::shared_ptr_helper, defined in archive/shared_ptr_helper.hpp, and it should work. As to why this is undocumented and in namespace detail I can only speculate, but this is what the other archive classes do.
/usr/include/boost/serialization/shared_ptr.hpp:133:9: error: ‘class my_iarchive’ has no member named ‘append’ /usr/include/boost/serialization/shared_ptr.hpp:139:5: error: ‘class my_iarchive’ has no member named ‘reset’
Stefan Strasser wrote:
Am 10.03.2013 01:27, schrieb Silviu P:
Hi,
I'm trying to serialize a boost::shared_ptr to a custom archive. The compiler complains about the archive missing methods 'append' and 'reset'. Does anyone know where I should look to find out more information about these two methods?
Derive your archive class from detail::shared_ptr_helper, defined in archive/shared_ptr_helper.hpp, and it should work.
As to why this is undocumented and in namespace detail I can only speculate, but this is what the other archive classes do.
I can explain this. shared_ptr does not fullfil the type requirements for a serializable object. That is, it doesn't model the serializable concept. So I had to include special archive code to permit serialization of shared_ptr. This is the only place in the library where there is a coupling between archive classes and any object type to be serialized. The real fix is to modify the serialization library to include the facility built for shared_ptr in a generic manner. This is doable but would require some work. It would also require expansion of the documentation and "serializable" concept. And of course tests etc. It's not a huge project, but it's not trivial either. And sooner or later it's going to be necessary to accomodate std::shared_ptr. Robert Ramey
Le 10/03/2013 17:56, Robert Ramey a écrit :
I can explain this.
shared_ptr does not fullfil the type requirements for a serializable object. That is, it doesn't model the serializable concept. So I had to include special archive code to permit serialization of shared_ptr. This is the only place in the library where there is a coupling between archive classes and any object type to be serialized.
The real fix is to modify the serialization library to include the facility built for shared_ptr in a generic manner. This is doable but would require some work. It would also require expansion of the documentation and "serializable" concept. And of course tests etc. It's not a huge project, but it's not trivial either. And sooner or later it's going to be necessary to accomodate std::shared_ptr.
Robert Ramey
Hi Robert, all Hmm, a question related to Robert's comment... In my group, we use boost::shared_ptr<> instances to implement smart relationships between various objects of a transcient physics data model (particle/nuclear decays in a large detector). The Boost/serialization lib (text + XML + eos::portable v5.0 I/O archives) is (and will be) used to store/load 10s of TB of experimental and simulated physics data. Our experimental project is supposed to last ~10 years and we do need to ensure backward compatibility for reading the data files we will accumulate during the experimental data collection and the production of large samples of monte-carlo data on various academic computing clusters. My question is: If, within some upcoming years, the Boost/Serialization migrates to "fullfil the type requirements for a serializable object" and, more, if we change boost::shared_ptr object into std::shared_ptr in our data model, do you think it will be possible to ensure the backward compatibility for our data storage ? I mean in a way as simple as using class Boost versioning... or even having a storage format completely unchanged ! thanks in advance. regards frc -- François Mauger LPC Caen-CNRS/IN2P3-UCBN-ENSICAEN Département de Physique -- Université de Caen Basse-Normandie
Francois Mauger wrote:
Le 10/03/2013 17:56, Robert Ramey a écrit :
I can explain this.
shared_ptr does not fullfil the type requirements for a serializable object. That is, it doesn't model the serializable concept. So I had to include special archive code to permit serialization of shared_ptr. This is the only place in the library where there is a coupling between archive classes and any object type to be serialized.
The real fix is to modify the serialization library to include the facility built for shared_ptr in a generic manner. This is doable but would require some work. It would also require expansion of the documentation and "serializable" concept. And of course tests etc. It's not a huge project, but it's not trivial either. And sooner or later it's going to be necessary to accomodate std::shared_ptr.
Robert Ramey
Hi Robert, all
Hmm, a question related to Robert's comment...
In my group, we use boost::shared_ptr<> instances to implement smart relationships between various objects of a transcient physics data model (particle/nuclear decays in a large detector).
The Boost/serialization lib (text + XML + eos::portable v5.0 I/O archives) is (and will be) used to store/load 10s of TB of experimental and simulated physics data.
Our experimental project is supposed to last ~10 years and we do need to ensure backward compatibility for reading the data files we will accumulate during the experimental data collection and the production of large samples of monte-carlo data on various academic computing clusters. My question is: If, within some upcoming years, the Boost/Serialization migrates to "fullfil the type requirements for a serializable object" and, more, if we change boost::shared_ptr object into std::shared_ptr in our data model, do you think it will be possible to ensure the backward compatibility for our data storage ? I mean in a way as simple as using class Boost versioning... or even having a storage format completely unchanged !
I would expect it to be either unchanged or use class versioning.
thanks in advance.
regards
frc
Le 15/03/2013 03:27, Robert Ramey a écrit : Robert Ramey
Hi Robert, all
Hmm, a question related to Robert's comment...
In my group, we use boost::shared_ptr<> instances to implement smart relationships between various objects of a transcient physics data model (particle/nuclear decays in a large detector).
The Boost/serialization lib (text + XML + eos::portable v5.0 I/O archives) is (and will be) used to store/load 10s of TB of experimental and simulated physics data.
Our experimental project is supposed to last ~10 years and we do need to ensure backward compatibility for reading the data files we will accumulate during the experimental data collection and the production of large samples of monte-carlo data on various academic computing clusters. My question is: If, within some upcoming years, the Boost/Serialization migrates to "fullfil the type requirements for a serializable object" and, more, if we change boost::shared_ptr object into std::shared_ptr in our data model, do you think it will be possible to ensure the backward compatibility for our data storage ? I mean in a way as simple as using class Boost versioning... or even having a storage format completely unchanged !
I would expect it to be either unchanged or use class versioning.
ok , so nothing worrying. that's sound good ! let's wait and see ! thanks. frc -- François Mauger LPC Caen-CNRS/IN2P3-UCBN-ENSICAEN Département de Physique -- Université de Caen Basse-Normandie
participants (4)
-
Francois Mauger -
Robert Ramey -
Silviu P -
Stefan Strasser