15

I was asked this question in one of my interviews, but I wasn't able to find out exactly why this concept is not there.

Please let me know.

Kevin Panko
  • 8,356
  • 19
  • 50
  • 61
Amit
  • 1,007
  • 5
  • 13
  • 19
  • By "copy" you mean "deep copy", do you? – Dan Diplo Apr 20 '10 at 15:26
  • Are you sure it wasn't a trick question? :) – Tony Apr 20 '10 at 15:30
  • 3
    I think the actual question is why there isn't a default one. http://en.wikipedia.org/wiki/Copy_constructor – juharr Apr 20 '10 at 15:31
  • @Dan Diplo: Deep Copy .... @Tony : I dont think so that its a tricky one. I told him that the functionality can be achieved by using the IClonable interface. And his answer was that, right it can be but why the concept is not there from the designing perspective. @Juharr: May be.... – Amit Apr 20 '10 at 16:06
  • 1
    Not needing a copy constructor is one of the *great* benefits of a garbage collector. Not spending time making copies is cream on top. – Hans Passant Apr 20 '10 at 17:21
  • 5
    @Hans Passant: What does garbage collection have to do with copying objects? If I use smart pointers in C++, do I suddenly have no need of a copy constructor? – David Thornley Apr 22 '10 at 21:31
  • Does this answer your question? [Copy constructor versus Clone()](https://stackoverflow.com/questions/3345389/copy-constructor-versus-clone) – Michael Freidgeim Dec 22 '22 at 10:44

3 Answers3

30

It's not built into the language because there is not a reasonable default implementation.

Copy constructors suffer from many of the same ambiguities as cloning. For example, whether you want to make a shallow copy or a deep copy depends on your particular circumstances.

Say you have an Order class with a Customer property. Should its copy constructor create a new customer or point to the original instance? Probably the original instance - but what about Order.Payment?

Worse, even when you do want to perform a deep copy, you may even not be able to create all of your subordinate objects, because their constructors (or comparable factory methods) may not be accessible.

In case that's not enough, this article on Java Design Issues highlights some other problems (like type truncation).

Community
  • 1
  • 1
Jeff Sternal
  • 47,787
  • 8
  • 93
  • 120
  • 3
    +1 for emphasis on there being no reasonable default behaviour for a built-in copy constructor. Spot on. – Paul Turner Apr 20 '10 at 15:46
  • 2
    Also, if it was built like the C++ one, you might get deep cloning whether you want it or not: this._PrivateFieldForCustomer = source._PrivateFieldForCustomer; <-- invokes copy constructor. – Lasse V. Karlsen Apr 21 '10 at 18:17
  • 4
    The C++ default is to copy all base classes and members, using their copy constructors. This isn't always what you want, but I consider it a reasonable default. – David Thornley Apr 22 '10 at 21:19
7

In what way does C# not support the idea of a copy constructor? You're more than free to create one that copies as deep as you like.

Adam Robinson
  • 182,639
  • 35
  • 285
  • 343
  • 5
    +1: C# doesn't have an implicitly defined copy constructor, but that's a C++ feature that arguably does more harm than good so you could say C# left it out due to lesson learned. – Sam Harwell Apr 20 '10 at 15:32
  • 1
    Depends on the point of view, I guess - for struct-type classes, it removed boiler plate code. Pretty much any language construct can be mis-used in the wrong hands. And C# throws out perfectly good features of C++ and Java that could be used well. Like local immutable local variables, which for some bizzare reason aren't in C# inspite of the rise of functional languages and it being a really easy feature to implement. Oh well. – Doug Aug 12 '15 at 21:36
  • 2
    @SamHarwell [much later comment] I do not agree at all about C++ copy ctor "doing more harm than good", as long as you know what "making a copy" means in C++, and how C++ type system works in general. Also from C++11 there's "move semantic" which allows - let me say - "a different type of copy". – user1832484 Apr 11 '20 at 15:42
1

Doesn't it?

class Foo
{
   public Foo (Foo other)   // copy ctor
   { ... }
}

But maybe I'm a bit rusty about what other rules apply in C++ (where the term copy constructor was coined).

H H
  • 263,252
  • 30
  • 330
  • 514
  • 4
    In C++ (C++11 at least), you can default a copy constructor by the following: "Foo(Foo other) = default;", which will typically default to calling all the field copy constructors (or assignments for primative types like int, float, and pointers). If no copy constructor exists for a field, the compiler will bomb out unhappily. – Doug Aug 12 '15 at 21:28