Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2003-10-03 16:43:43


Vladimr Prus wrote:

>Robert, could you clarify if default ctor is ineeded required in all cases?

Short answer is no. The serialization system does not impose any
requirement regarding constructors.

Here is a slightly longer explantation:

case I Serialization objects already created - the most common case

Objects already exist no creation necessary. serialization saves
and reloads their current state.

case II Serialization of pointers

Objects must be created. Default non-intrusive load uses a default
constructor ( which may be private). If an application requires
a non - default constructor a non - default load and save must
be specified. Usually this will

a) save construction parameters before saving the object.
b) load the saved construction parameters before creating the object.
At the time of object creation the construction parameters are
available so all is well.

All the above is explained in the documentation.

This circumstance which provoked the current confusion is a result
of my interpretation of what it means to serialize a collection - in
this case a vector.

In such a case the most natural (to me) interpretation was to clear the
vector and re-create the vector elements - STL calls default constructor
in this case which you chose to make private to inhibit other potential
callers.

My response was that I didn't believe that one should even have
a default constructor in such cases. I showed how to override
the collection load function to implement such a point of view.

Upon reflection, I've come to believe my response was beside the point
and confused the issue. I am going to tweak the library so that
loading of collections is handled specially and given access to
any private default constructor. I now believe that this will not
create any of the problems I originally envisioned.

I believe that this should address all concerns raised.

Robert Ramey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk