Re: [boost] Interest in boost.deepcopy

Subject: Re: [boost] Interest in boost.deepcopy
From: Allan Johns (allan.johns_at_[hidden])
Date: 2011-10-25 19:37:22

Sure.

Consider a (simplified) subset of the data types in my case:

class Object{};

class AttributeBase : public Object{}

template<T> class Attribute : public AttributeBase { shared_ptr<T> value; }

template<T> class Buffer : public Object { shared_ptr<std::vector<T>> data;
shared_ptr<Table<K,shared_ptr<AttributeBase>> attributes; }

template<K> class Table : public Object { std::map<K,shared_ptr<Object>>
map; }

These objects are often arranged in a hierarchy - a table contains
attributes, other tables, or buffers. An attribute in turn contains a
shared_ptr to a pod type, and a buffer contains data in an std::vector (that
may become a shared resource due to COW behaviour), and also contains a
table of attributes. There may be cyclic dependencies that I can't do
anything about (the user has created the hierarchy, and I can't suffer the
cost of cyclic detection at runtime).

I need to create a separate copy of some subset of this hierarchy, and this
is initiated by the user - it might be a buffer, a table, an attribute, etc.

At the moment this is achieved by each class containing a virtual clone()
function that implements the "deep" copy. This function is passed a "cloning
context" instance, which is a map of newly allocated instances, so that
duplicates are avoided (ie shared objects). There is a special case (Buffer)
where a "clone" operation does not result in an identical and separate copy
of the data, instead the internal std::vector is shared with the new Buffer
until such time that either are attempted to be written to (COW).

Thus I have three implementations of clone() in this example, and I'm using
a virtual function.

If the deepcopy library that I'm describing existed, then two things would
happen:

- I'd drop the virtual.

- I'd just have deepcopy specializations for Table, Buffer etc. In the
'typical' cloning cases (everything but Buffer), the implementation would be
a one-liner, deferring deep copying of the already-supported types
(shared_ptr, std::map) to the existing deepcopy implementations.

The deepcopy library would take care of the object tracking side of things
(avoiding duplicates etc), much like boost.serialize does currently.

In the trivial case (ie one where there is no specific deepcopy behaviour
like COW) the end result would be the same as boost.serializing the original
hierarchy to memory, then back out again.

hth
A

On Wed, Oct 26, 2011 at 10:04 AM, Jeffrey Lee Hellrung, Jr. <
jeffrey.hellrung_at_[hidden]> wrote:

> On Tue, Oct 25, 2011 at 3:54 PM, Allan Johns <allan.johns_at_[hidden]
> >wrote:
>
> > In my case I have several data types - tables, buffers, tuples,
> attributes
> > etc. I need to be able to clone (ie deepcopy) any part of one of these
> > hierarchical structures... there is no "entire structure", if you will.
> >
> > I understand what's being said about memory ownership, but in this case I
> > have full control of my problem domain, and such a generic deep copy
> > library
> > would be useful and save time - otherwise I'm just going to have to
> > implement deep copy behaviour inside of all my classes anyway (which is
> > actually what I have at the moment). This pattern has come up several
> times
> > before in my work, so it isn't a one-off, and the motivation is not to
> deal
> > with cyclic dependencies (although that should probably be dealt with).
> >
> > Perhaps there should be a 'deep copy context' that you can create for
> your
> > own code or share from other libraries, so for eg one library's idea of
> > what
> > "deep copying" an std::vector is, can differ from another library's.
> Would
> > this address your concern over ambiguity of memory ownership?
> >
> > Given that this behaviour is implemented as a standard module in another
> > language (python) I'm surprised it's being dismissed so easily?
> >
> > Allan
> >
> > ps -- I'm not a python programmer, just wanted to make that clear! Well I
> > do
> > use it but... you know what I mean.
> >
>
> It would help *me* if you gave a more concrete example of why this is
> useful...I feel like you're speaking in generalities that I'm having
> trouble
> connecting with :/  And, if it helps me, it might help others.
>
> - Jeff
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>