Re: Serialization (Persistence) library draft submission

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-03-01 03:51:24

rameysb wrote:
> Permit me to attempt to summarize the recent discussion:

> Consensus
> =========
> I believe there is wide agreement on this aspects of the system.
> [snip]

I don't think there's consensus on describe vs. load/save question. Having 
recorded this, I suggest that we postpone this question until other issues 
are resolved.

> Design issues
> =============
> a) save/restore of const members and references
>    i) These can only be set during construction.
>    ii) serialization can be characterised as saving an restoration
>        of an object's state.  since these members aren't mutable
>        they shouldn't be subject to serialization.
>
>    The view has been expressed that this system should be able
>    restore const and reference member variables.

I don't have a strong opinion here yet.

> b) Requirement for default constructor and related issues
>    For objects serialized through a pointer, the library
>    implementation of object creation requires that the serializable
>    class have a default constructor. I believe that this is a
>    necessary and reasonable requirement.  

OK with me.

> However, If an application
>    is such that this is a burdensome requirement or creates
>    some other conflict then usage of this aspect of the library would
>    have to  be avoided for the particular class.  How to do this is
>    illustrated by the following example:

> class A
> {
> 	B *b;
> 	void load(iarchive &ar, int file_version)
> 	{
> 		// replace the library provided creation with your own
> 		int y;
> 		ar >> y;
> 		b = new B(y);
> 		// restore non-const stuff
> 		ar >> *b;
> 	}

> No default constructor will be necessary. (note: code modifications
> ight be required to implement this but I believe it is possible an
> hat they would not be difficult.).

I believe one can do even better by creating static member of class B which 
will take iarchive and return B*; it feels more clean to me. Probably, some 
support for this should be included, but I don't have any concrete 
suggestion.  

> Resolved (at least in my mind) alterations
> ==========================================
> I have concluded that the value of these modifications exceeds the
> cost of thier implemention.  I do not believe there would objections
> to these.
>
> a) better checking to detect errors in serialization of pointers

Sure. Personally I think that cases like serializing the same object via 
pointer and directly (in the wrong order), should result in exception (not 
assert).

> c) binary format archive
>    issues - here is a summary of the binary/text archive issue
>    i)  binary data is fundementally non-portable
>    ii)  converting to/from text alters floating/double numbers
>    iii) binary storage is considered more efficient
>
>    I would propose that two new classes be created - say
> binary_iarchive
>    and binary_oarchive that would use binary rather than text output.

Could you clarify if load/save methods that take {i,o}archive will work with 
those new classes. Also, it should be possible to add new formats relatively 
easily (XML i/o comes to mind first). For example, XTL uses a separate 
concept called "format driver", which defines the psysical storage of 
information. Maybe, it's worth using such a concept?

> Making these changes woudl take about a 10 days.  

I'm looking forward.

- Volodya