Subject: Re: [boost] Interest in boost.deepcopy
From: Allan Johns (allan.johns_at_[hidden])
Date: 2011-10-25 18:54:57
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?
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 <
> >Consider an object hierarchy in which there may be multiple references to
> >shared objects. A deep copy should give an identical, but entirely
> >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
> >You could argue that I should write a custom smart pointer to perform a
> >copy in its copy constructor, but for multiple reasons I'd quite like to
> >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.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk