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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-07 08:01:56

Dave Harris wrote:

> 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 seems like your suggestion is really independent from my original request.
I wanted STL container serialization to access private ctor vis
boost::serialization::access. Your suggestion seemed to imply that it's not
really necessary: that 'load_construct' will work even without that private
access -- and I argued with that statement.

>> 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.

Then, I see the point. You've simplifying the work for user when he's about
to customize pointer loading. That's good.

One question remains: can 'load_construct' be used to create object in raw
memory, especially if the object was not saved via pointer? Looks like not,
since 'load/save' should not be called directly. Then, stl serialization
still need extra access rights.

- Volodya