Boost logo

Boost :

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

> 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

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