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
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 www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk