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:49:38

On Wed, Oct 26, 2011 at 10:17 AM, Dave Abrahams <dave_at_[hidden]> wrote:

>
> on Tue Oct 25 2011, Allan Johns <allan.johns-AT-drdstudios.com> 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?
>
> Pickling is considered "evil" in the BuildBot project precisely because
> you can't control the boundaries
> (http://irclogs.jackgrigg.com/irc.freenode.net/buildbot/2011-05-09),
> though I realize it's sometimes convenient.
>
> Seems to me that you could tackle this need by implementing a special
> "cloning_archive" type for Boost.Serialization, and be done with it.
>

I very much wanted to do exactly this Dave, and initially I did. But it
didn't really work out, especially taking custom deepcopy behaviour like COW
into account. I did end up with something that worked, but it was pretty
clunky.

One example: boost.serialize code already exists for std::vector etc.
However, in cases where assignment is equivalent to a deep copy (such as
std::vector<int>) the actual data serialization had to be skipped. So I
needed an "assignment_is_deepcopy" trait for all types involved. Then there
were temporaries to worry about. Existing class serialization code can copy
data to a temporary variable, then serialize from there. This will break
"clone" serializing - you need to somehow tell the archive that the data in
this case is temporary and needs to be copied in full, rather than just
serializing a reference, which is the typical case, and necessary for
optimised performance (simply copying all data is not acceptable - too
expensive). So a tmp<> decorater class was needed, which meant that the
solution wasn't extensible to existing serialization code from other
libraries.

There is also the unnecessary overhead involved. Boost.serialization stores
tracking data that isn't necessary when you don't need to worry about
persistence (for example, class ids etc). Not to mention the ubiquitous
boost::serialize::nvp, which is unnecessary here.

thx
A

>
>
> --
> Dave Abrahams
> BoostPro Computing
> http://www.boostpro.com
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>