Re: [boost] Re: Re: Re: Re: [serialization] default-constructors

From: Dave Harris (brangdon_at_[hidden])
Date: 2003-10-06 12:59:58

In-Reply-To: <blrqm6$aph$1_at_[hidden]>
ghost_at_[hidden] (Vladimir Prus) wrote (abridged):
> Actually, it adds work for me. I need one additional friend declaration.

Really? I've not looked at how the friend declarations work. It seems to 
me that where previously you would make the pointer version of load a 
friend, now you make load_construct a friend.

I vaguely remember some of the previous messages using a more indirect 
route - granting access to boost::serialization::access, which presumably 
grants access to the default implementation of load. In which case, the 
same mechanism can grant access to the default implementation of 
load_construct instead. We don't need both pointer load and load_construct 
to have access.

> I might be missing something, but looks you're splitting the last 
> "load" in "load" and "load_construct". You've shown how to use
> "load_construct" part, but is there any need to use "load", after
> it's split from "load_construct". If no, then maybe it's not good
> to call it "load"? 

I don't think there's any need to use the old pointer version of "load". 
Its purpose is now memory management. The serialisation library does not 
need to offer the ability to customise memory allocation, and if it does, 
it might be better done with some kind of allocator interface. So I would 
be happy if this function became undocumented and removed from the 
interface. That way we still have just 4 functions to deal with, rather 
than 6.

> Maybe, what you're after is moving the "try"/"catch" from pointer "load"
> into serialization lib, and making pointer "load" accept uninitialized
> pointer?

Yes, exactly. That's another way of putting it.

Except that I don't think "load" is a good name. It does more than load - 
it constructs the object too.

-- Dave Harris, Nottingham, UK