2010-04-20 5 views
12

Ich wurde diese Frage in einem meiner Interviews gestellt, aber ich konnte nicht genau herausfinden, warum dieses Konzept nicht da ist.Warum unterstützt C# nicht das Konzept von Copy Constructor?

Bitte lassen Sie es mich wissen.

+0

Mit "kopieren" meinen Sie "tiefe Kopie", oder? –

+0

Sind Sie sicher, dass es keine Trickfrage war? :) – Tony

+2

Ich denke, die eigentliche Frage ist, warum es keinen Standard gibt. http://en.wikipedia.org/wiki/Copy_constructor – juharr

Antwort

2

Nicht wahr?

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

Aber vielleicht bin ich ein wenig eingerostet, was andere Regeln gelten in C++ (wobei der Begriff Copykonstruktor geprägt wurde).

+0

In C++ (mindestens C++ 11) können Sie einen Kopierkonstruktor wie folgt vorgeben: "Foo (Foo other) = default;", das standardmäßig standardmäßig alle Feldkopiekonstruktoren (oder Zuweisungen für primative Typen) aufruft wie int, float und pointer). Wenn kein Kopierkonstruktor für ein Feld existiert, bombardiert der Compiler unglücklicherweise. – Doug

6

Inwiefern unterstützt C# nicht die Idee eines Kopierkonstruktors? Sie können mehr als nur eine erstellen, die so tief kopiert, wie Sie möchten.

+4

+1: C# hat keinen implizit definierten Kopierkonstruktor, aber das ist eine C++ - Funktion, die wohl eher schadet als nützt, also könnte man sagen, dass C# aufgrund von Lernerfahrungen ausgelassen wurde. –

+0

Abhängig von der Sicht, ich denke - für die Struktur-Typ-Klassen, entfernt es Kesselblech-Code. So ziemlich jedes Sprachkonstrukt kann in den falschen Händen missbraucht werden. Und C# verwirft perfekt gute Features von C++ und Java, die gut genutzt werden könnten. Wie lokale unveränderliche lokale Variablen, die aus irgendeinem Grund nicht in C# sind, trotz des Anstiegs der funktionalen Sprachen und es ist ein wirklich einfaches Feature zu implementieren. Naja. – Doug

28

Es ist nicht in die Sprache integriert, weil keine sinnvolle Standardimplementierung ist.

Kopieren Konstruktoren suffer from many of the same ambiguities as cloning. Ob Sie beispielsweise eine flache Kopie oder eine Tiefenkopie erstellen möchten, hängt von Ihren speziellen Umständen ab.

Angenommen, Sie haben eine Order Klasse mit einer Customer Eigenschaft. Sollte der Kopierkonstruktor einen neuen Kunden erstellen oder auf die ursprüngliche Instanz verweisen? Wahrscheinlich die ursprüngliche Instanz - aber was ist mit Order.Payment?

Schlimmer noch, auch wenn Sie tun eine tiefe Kopie durchführen möchten, können Sie möglicherweise nicht alle untergeordneten Objekte erstellen, da ihre Konstruktoren (oder vergleichbare Factory-Methoden) möglicherweise nicht zugänglich sind.

Wenn das nicht genug ist, markiert this article on Java Design Issues einige andere Probleme (wie Typ Trunkierung).

+2

+1 für die Betonung, dass es kein vernünftiges Standardverhalten für einen eingebauten Kopierkonstruktor gibt. Spot auf. –

+2

Auch wenn es wie das C++ gebaut wurde, können Sie tief klonen, ob Sie es wollen oder nicht: this._PrivateFieldForCustomer = source._PrivateFieldForCustomer; <- ruft den Kopierkonstruktor auf. –

+2

Der C++ - Standard besteht darin, alle Basisklassen und Member mithilfe ihrer Kopierkonstruktoren zu kopieren. Das ist nicht immer das was du willst, aber ich halte es für einen vernünftigen Standard. –