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@gmail.com> wrote:
On Tue, Oct 25, 2011 at 3:54 PM, Allan Johns <allan.johns@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?
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