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

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-05 13:59:42

Robert Ramey <ramey_at_[hidden]> writes:

> Dave Abrahams wrote:
>
>>You can deserialize non-collections without constructing them
>>somehow??  That surprises me.  Or do you mean something else?
>
> well, isn't an array a kind of collection?

Sure.  You can deserialize an array without constructing its elements?

> In the case of arrays, the elments are always constructed so no
> consturction is required.

??  As with any other object, an array's subobjects/elements are only
already constructed if you pass the array into the deserialization
code.  There are of course other ways to handle that, e.g. by passing
raw storage or optional<T[N]> or letting the array be allocated
dynamically by deserialization.

> Some application is might consider the number of elements
> in an STL collection a constant - similar to a const member
> variable.  For this application, my current implementation
> which clears the collection and rebuilds if from the stream
> might be considered unsatisfactory. 
>
> This brings up the question of const member variables - should
> these be reconstructed from the serialization stream or should
> they be truely considered const? - fixed only at time of object
> creation?

You can handle all those issues by consistenly having deserialization
construct the objects it's deserializing.

> Then what about volatile - I thought I knew what this means
> but recent posts make me wonder.

It doesn't mean much, except to provide a constraint on the type
system.

> The real point is that these are application/programmer
> dependant concepts and agreement can never be achieved
> so the framework has to be overridable in the right places.

We agree about that, at least.  I'm still not convinced that
deserialization into pre-constructed objects is important, but I'm
willing to be convinced otherwise.

> I believe this library fullfills this requirement.

Maybe so.  I'm still not sure.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com