On Wed, Oct 26, 2011 at 10:17 AM, Dave Abrahams <dave@boostpro.com> 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