Boost logo

Boost :

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

> 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

> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at