Boost logo

Boost :

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

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