Hi
On 25/09/2011 00:08, Alfredo Correa wrote:
Good. Having settled on that, I think it would be cool to have the *option* to save the class name (or other tag information) with the object. Just a suggestion for Boost.Serialization.XML
I would suggest that nothing should be changed in the core Boost/Serialization XML lib, even if what you propose is fancy and even if it is an option (who would choose the "name of the class" to be saved ? How to make sure that the convention for class naming is the same while reading and writing ? I guess it addresses some new problems...). Rather than acking the BS lib, what you asked for could be probably easily implemented by some specific I/O manager dedicated for your specific need during I/O operations. When I serialize some heterogeneous sets of objects in any kind of archives (text/XML/eos::portable_binary), I first store/load a "serialization tag" (std::string) that identifies the type/class of the next object to be stored|loaded. It is thus my responsability to manage a set of known tags associated to the classes I need to serialize. So it turns out that any serializable data is confined in some kind of virtual container, together with some kind of class ID: <archive> serial_tag #0 data_record #0 serial_tag #1 data_record #1 ... serial_tag #N data_record #N </archive> There is also no problem to add meta-informations if needed <archive> serial_tag #0 meta_info #0 data_record #0 ... </archive> Of course, it implies some smarter management of the I/O operations and some hard-coded factory (in a basic implementation). But it is very convenient for debugging and compatible with all kind of archives. This mechanism is clearly a brute force approach and maybe some people consider this as inelegant. Anyway I have used this in production code for years and it is very robust. Note that it is different from the BOOST_CLASS_EXPORT mechanism which implies all your objects must be serialized by a base pointer and inherited from a unique abstract class/interface.
I think of the quantity example because all quantities saved to xml_archive look exactly the same regardless of whether they are the same dimension or not, so it exists the possibility that quantitysi::length is saved, but then read as quantitysi::time.
Now about a workaround from the point of view of Boost.Units, suppose I want to ensure that additional information (spurious for reconstruction but useful as a check and human reader) with the current implementation. Currently the serialization of boost.unit.quantity is:
// boost/units/io.hpp template
inline void serialize(Archive& ar,boost::units::quantity & q,const unsigned int /*version*/){ ar& boost::serialization::make_nvp("value", q.value); //basically this in the code }
Could it be possible for you to use a wrapper class with the additional meta-info you need rather than to rely on some intrusive modification of the core functionality of the lib ? struct quantity_wrapper<...> { boost::units::quantity<...> q; std::string more_info; void serialize(...); }; cheers frc -- -- François Mauger Groupe "Interactions Fondamentales et Nature du Neutrino" NEMO-3/SuperNEMO Collaboration LPC Caen-CNRS/IN2P3-UCBN-ENSICAEN Département de Physique -- Université de Caen Basse-Normandie Adresse/address: Laboratoire de Physique Corpusculaire de Caen (UMR 6534) ENSICAEN 6, Boulevard du Marechal Juin 14050 CAEN Cedex FRANCE Courriel/e-mail: mauger@lpccaen.in2p3.fr Tél./phone: 02 31 45 25 12 / (+33) 2 31 45 25 12 Fax: 02 31 45 25 49 / (+33) 2 31 45 25 49