Re: [Boost-users] [serialization] [units] class_id and class_name to describe quantity dimension in serilization archive

Subject: Re: [Boost-users] [serialization] [units] class_id and class_name to describe quantity dimension in serilization archive
From: François Mauger (mauger_at_[hidden])
Date: 2011-09-25 04:05:49

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
> quantity<si::length>  is saved, but then read as quantity<si::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<class Archive,class Unit,class Y>
> inline void serialize(Archive&  ar,boost::units::quantity<Unit,Y>&
> 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_at_[hidden]
Tél./phone:      [phone]
Fax:             02 31 45 25 49 / ([phone]