Boost logo

Boost :

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 :-)

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