blocks|key|1350167|text|我认为这个问题的答案非常有趣。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1350168|首先，我相信在Java中所有的对象都在堆上，虽然你没有指针，但你确实有“引用”。引用有复制语法，java在内部跟踪引用计数，这样它的垃圾收集器就知道什么是安全的。|1350169|由于您仅通过可复制引用访问对象，因此需要复制对象的实际次数大大减少(例如，在C%2B%2B中，仅将对象(按值)传递给函数会导致复制构造新对象，而在Java语言中，仅传递对对象的引用)。设计者可能认为clone()就足以满足剩下的用法。|1350170|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I think the answer to this is very interesting.

For one, I believe that in Java all objects are on the heap, and while you don't have pointers, you do have "References". References have copy symantics and java internally keeps track of reference counts so that its garbage collector knows whats safe to get rid of.

Since you only access objects through copyable references, the actual number of times you need to copy an object is greatly reduced (for example, in C++ just passing an object to a function (by value) results in new objects being copy constructed, in Java only the reference to the object is passed). The designers probably figured that clone() would be enough for the remaining uses.

&nbsp;

blocks|key|1565744|text|这只是我的观点(我相信有一个合理的答案)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1565745|当您通过值发送或返回类的实例时，C%2B%2B中的复制构造函数主要是有用的，因为这是复制构造函数被透明激活的时候。|1565746|因为在Java中，所有的东西都是通过引用返回的，而VM是面向动态分配的，所以没有理由使用复制构造函数的复杂性。|1565747|此外，由于一切都是通过引用实现的，因此开发人员通常必须提供自己的实现和如何克隆字段的决策。|1565748|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

This is just my opinion (I am sure there is a justifiable answer)

Copy constructors in C++ are primarily useful when you are sending or returning instances of classes by value, since that is when the copy constructor is transparently activated.

Since in Java everything is returned by reference, and the VM is geared towards dynamic allocation, there really wasn't a justification for the complexities of a copy constructor. 

In addition, since everything is by reference, a developer would often have to provide their own implementation and decision on how to clone fields.

blocks|key|1565545|text|我猜他们认为你可以只做一个clone()方法？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1565546|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Guess they figured you can just make a clone() method instead?

blocks|key|1350356|text|在某种程度上是这样。当浅层复制正常时，您可以使用clone()](http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#clone(%2529%2529)，而当它们不合适时，您必须实现像C%2B%2B一样的深层复制。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1350357|唯一的本质区别是它是一个工厂方法，而不是构造函数本身，但就灵活性和可测试性而言，这可能是一件好事。|1350358|entityMap|0|LINK|mutability|MUTABLE|url|[http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#clone()|1|http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#clone(%2529%2529^0|O|7|0|X|22|1|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]|$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

It kind of does. When shallow copies are okay you have [clone()](<a href="http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#clone())" rel="nofollow noreferrer">http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#clone())</a> and when they aren't you have to implement a deep copy just like C++.

The only substantive difference is that it's a factory method rather than a constructor proper, but in terms of flexibility and testability that's probably a good thing.

blocks|key|1565947|text|我不是一个很好的C%2B%2B程序员，但我似乎记得关于“三个朋友”的规则--复制构造函数、赋值操作符和析构函数。如果你有一个，那么你可能需要这三个。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1565948|所以，也许在语言中没有析构函数，他们就不想包含复制构造函数？只是猜测而已。|1565949|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I'm not much of a C++ programmer, but I do seem to remember a rule about the "three amigos" - copy constructor, assignment operator, and destructor. If you have one, then you likely need all three.

So maybe without a destructor in the language, they didn't want to include a copy constructor? Just a guess.

blocks|key|1350577|text|嗯，它可以。它只是不是隐式创建的。如果非要我猜的话，这可能与Java对象总是堆分配的事实有关。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1350578|在C%2B%2B中，默认的复制构造函数是成员式的浅复制。如果一个类拥有在堆上分配的内存(通过原始指针)，这将导致副本与原始共享内部，这不是您想要的。|1350579|想象一下，Java有这样的行为。任何拥有作为对象的字段的类(read:本质上是所有的)都会有错误的行为，您需要自己重写它。对于99%25的案例来说，你并没有为任何人省去任何麻烦。此外，您刚刚为自己创建了一个微妙的陷阱-假设您意外地忘记了覆盖默认的复制构造函数。如果它是默认生成的，并且您尝试使用它，编译器将完全不会报错，但您的程序将在运行时表现不佳。|1350580|即使他们创建了一个默认的复制构造函数来执行深度复制，我也不确定这是否会特别有用。您不仅倾向于在Java语言中比在C%2B%2B中执行更少的复制，而且您并不总是希望对字段进行深度复制。|1350581|您刚刚拥有的对象和您持有引用的对象是相同的，只是字段而已。所有权和借款不是第一类概念。对于你拥有的对象，你会想要深度复制它们(除非它们是不可变的，在这种情况下你不应该麻烦)，而对于你只是持有引用的对象，你想要复制引用。|1350582|我会争辩说，一个只是盲目地对所有东西进行深度复制的复制构造函数也不适合许多类。当然比肤浅的复制更多，尽管是默认的复制。|1350583|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

Well, it can. It just doesn't get created implicitly. If I had to guess, it's probably related to the fact that Java objects are always heap-allocated.

In C++, the default copy constructor is a member-wise shallow copy. If a class owns memory allocated on the heap (via a raw pointer), this will cause the copy to share internals with the original, which is not what you want.

Imagine for a moment that Java had this behavior. Any class that has fields that are objects (read: essentially all of them) would have the wrong behavior, and you'd need to override it yourself. For 99% of cases, you haven't saved anyone any trouble. Further, you've just created a subtle trap for yourself - imagine you accidentally forget to override the default copy constructor. If it was generated by default, and you try to use it, the compiler won't complain at all, but your program will misbehave at runtime.

Even if they made a default copy constructor that performs a deep copy, I'm not sure that would be particularly useful. Not only do you tend to perform fewer copies in Java than C++ anyway, but you don't always want to deep copy a field.

Objects that you just own, and objects that you hold references to because you need them, but aren't responsible for, are the same - just fields. Ownership and borrowing are not first class concepts. For objects you own, you'd want to deep copy them (unless they're immutable, in which case you shouldn't bother), and for objects you just hold a reference to, you want to copy the reference.

I would argue that a copy constructor that just mindlessly deep-copies everything wouldn't be suitable for many classes, either. Certainly more than shallow-copying by default, though.

问为什么Java没有复制构造函数？
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Java没有复制构造函数？EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Java没有复制构造函数？
EN