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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost