Boost logo

Boost :

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, (David A. Greene) wrote:

> Dave Abrahams <dave_at_[hidden]> writes:
>> on Mon Oct 24 2011, Allan Johns <> 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*>

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at