Re: [boost] Interest in boost.deepcopy

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
  the copy.

* 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*>
  semantics).

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