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. On Wed, Oct 26, 2011 at 8:33 AM, Simonson, Lucanus J < lucanus.j.simonson@intel.com> wrote:
Consider an object hierarchy in which there may be multiple references to shared objects. A deep copy should give an identical, but entirely separate copy of the entire structure.
Also consider eg std::map<std::string,T*>... the std::map copy constructor is not going to create new instances of T in the copy - this is a shallow copy.
You could argue that I should write a custom smart pointer to perform a deep copy in its copy constructor, but for multiple reasons I'd quite like to not have to do this, and to use boost::shared_ptr as normal.
No smart pointer, a separate class for each instance of the need for deep copy. You have a missing object in your design that owns the "entire structure" and implements the deep copy as its assignment operator. That object is responsible for de-duplicating pointers to shared objects. Whenever this comes up in whatever guise, a C++ garbage collector or smarter smart pointer, the answer is always the same: get the ownership of memory clear in you design and use RAII to manage memory and assignment operator to make copies. You shouldn't be trying to make sense of cyclical dependencies of raw pointers in the first place. Fix the bad design, don't enable it with a clever library.
Regards, Luke
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost