[boost] Re: Re: [serialization] default-constructors (was Re[serialization]problem deserializing vectors)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-06 00:07:04

Robert Ramey wrote:

> 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.

Ok.

> 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.

Thanks for the explanation. I've missed that part of the docs.

> 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.

I believe that's the right solution! Thanks.

- Volodya