[boost] Re: serialising vectors

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-15 16:05:18

Dave Harris wrote:

> I would bundle the construction with the loading, to help in cases where 
> the construction is all that's required (or permitted)
> 
> Also, David's vision is somewhat different to mine and I don't understand 
> it in detail. I think he is saying that uninitialized_load() is the only 
> load the user should need to write, and initialised_load() should be 
> written in terms of it. 

I don't know what those names mean, so it's hard to say.  What I think 
is that for optimal flexibility the user should only ever have to write 
one object loading function which deserializes and constructs the object 
into memory supplied by the system, by whatever means.

When I think carefully about the constraints that C++ imposes on us, 
though, I find it difficult to see how that can cover the cases I was 
thinking of.  For example, suppose:

   class X { ... Y y; };

Now we're writing X's deserialization function.  Suppose it can even be 
a constructor of X, which gives us about as much power over X's 
initialization as possible.  If Y has no publically-available default 
constructor and no deserialization constructor, how do we deserialize 
it?  What we'd like is to be able to say, "I've got memory for a Y 
member here; construct it into this memory using this deserialization 
function".  Unfortunately that's not possible.  Construction in C++ is 
always intrusive.

I think for efficient container construction, copy elision may allow RVO 
to give us an efficient interface, provided the iterator range container 
constructors are used... though I'm not confident that all copies can be 
avoided and I doubt that even if they could, they would be in real life.

So, I'm less and less confident that in-place construction is much of a win.

 > Presumably using a second object and assignment
> (or swap?), or else destructing the original object and constructing a new 
> object at that same location. 

Yikes!  I wasn't thinking anything like that!

 > If I have this right, it sounds less
> efficient in the common case, so I've probably misunderstood. And I'd want 
> to understand before making any final decisions :-)