Subject: Re: [boost] Interest in boost.deepcopy
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-11-02 18:20:59
on Wed Nov 02 2011, greened-AT-obbligato.org (David A. Greene) wrote:
> Dave Abrahams <dave_at_[hidden]> writes:
>> on Mon Oct 24 2011, Allan Johns <allan.johns-AT-drdstudios.com> wrote:
>>> Just gauging initial interest in a boost.deepcopy library
>> <pet peeve alert>
>> Sorry to slam this idea out of the gate, but the whole notion of a
>> "deep copy" is broken and wrong (in my humble opinion). When you say
>> you're going to "deep copy" an object it shows you don't understand
>> the boundaries of that object's value. The object's value is copied
>> by its copy constructor, and compared by its operator== (assuming it
>> has one). If your "deep copy" extends beyond the boundaries of the
>> value, there's no way of knowing how far it should extend.
> Fascinating discussion. I'm curious about your statement here. Do you
> object to "deep copy" as implemented in a copy constructor or the notion
> of "deep copy" of some aggregate data structure in general?
I object to the terms "shallow copy" and "deep copy," because they're
imprecise, and because they tend to confuse the notion of copying (full
stop), which is fundamental and well-defined. I want to be able to talk
about "copying this list of pointers" without someone saying "wait, do
you mean a deep or a shallow copy?" And when they do say that, what do
you suppose "shallow" and "deep" mean? It isn't clear:
* shallow might mean that the two lists share storage, so that changing
the first pointer in the original list changes the first pointer in
* shallow might mean merely that no effort is made to clone the objects
being pointed to by the list elements (i.e. ordinary std::list<T*>
So then I need to ask for a definition of shallow/deep. The whole thing
is a mess that arises all the time in languages with mutation but
without an intrinsic notion of value semantics, but there's no reason we
should go into that territory in C++.
> For example, I have often needed to clone some branch of a tree data
> structure where nodes contain pointers to other nodes. For me this is
> in the context of a compiler and subtree cloning is a convenient way to
> perform code duplication.
Awesome. Cloning a subtree is a well-defined operation. If nodes in
the tree happen to contain pointers that aren't part of the tree's
parent/child/sibling link structure, I know they get copied bitwise and
that's the end of it.
> In the past I have implemented a virtual clone() member for each kind
> of tree node in order to get polymorphic behavior. clone() clones
> child nodes and all that.
> If your objection covers cases like the above, I am very interested in
> alternative solutions.
It might make sense to create a class that encapsulates a subtree and
whose copy ctor implements the clone operation. Then again, it might
not; depends on your application.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk