为什么在实施NSCopying时区域总是为零？ [英] Why zone is always nil while implementing NSCopying?

问题描述

这可能是一个简单的问题，但为什么在我的课堂上实施NSCopying协议，我得到 zone == nil

It may be simple question, but why implementing NSCopying protocol in my class, I get zone == nil

- (id)copyWithZone:(NSZone *)zone
{
    if (zone == nil)
        NSLog(@"why this is allways nil");

    (...)
}

这称为将此方法用于带对象的副本数组。

This is called using this method for copy array with objects.

[[NSArray alloc] initWithArray:myArray copyItems:YES]];

推荐答案

凯文和罗宾的答案是最准确的。奥斯卡的答案非常接近正确。但是Gnustep文档和logancautrell存在区域的原因都不正确。

Kevin's and Robin's answer is the most accurate. Oscar's answer is pretty close to correct. But neither the Gnustep documentation nor logancautrell's reasons for the existence of zones is quite correct.

区域最初是创建的 - 首先是NXZone，然后是NSZone - 以确保分配的对象来自单个区域的内存相对连续，这是真的。事实证明，这并没有减少应用程序使用的内存量;在大多数情况下，它会稍微增加它。

Zones were originally created -- first NXZone, then NSZone -- to ensure that objects allocated from a single zone would be relatively contiguous in memory, that much is true. As it turns out, this does not reduce the amount of memory an app uses; it ends up increasing it slightly, in most cases.

更大的目的是能够大规模破坏一组对象。

The larger purpose was to be able to mass destroy a set of objects.

例如，如果您要将复杂的文档加载到基于文档的应用程序中，那么在文档关闭时拆除对象图形实际上可能非常昂贵。

For example, if you were to load a complicated document into a document based application, tear-down of the object graph when the document was closed could actually be quite significantly expensive.

因此，如果文档的所有对象都是从单个区域和分配的，那个区域的分配元数据也在该区域中，那么破坏与文档相关的所有对象将像简单地破坏区域一样便宜（这非常便宜 - 这里，系统，让这些页面恢复 - 一个函数调用）。

Thus, if all the objects for a document were allocated from a single zone and the allocation metadata for that zone was also in that zone, then destruction of all objects related to the document would be as cheap as simply destroying the zone (which was really cheap -- "here, system, have these pages back" -- one function call).

这被证明是行不通的。如果对区域中某个对象的单个引用泄漏出该区域，那么一旦文档关闭，您的应用就会 BOOM ，并且该对象无法告诉所指的任何内容它要停下来。其次，这个模型也成为GC'd系统中经常遇到的稀缺资源问题的牺牲品。也就是说，如果文档的对象图保留在非内存资源上，则在区域销毁之前无法有效地清理所述资源。

This proved unworkable. If a single reference to an object in the zone leaked out of the zone, then your app would go BOOM as soon as the document was closed and there was no way for the object to tell whatever was referring to it to stop. Secondly, this model also fell prey to the "scarce resource" problem so often encountered in GC'd system. That is, if the object graph of the document held onto non-memory resources, there was no way to clean up said resources efficiently prior to zone destruction.

最后，并没有足够的表现胜利（你经常关闭复杂文件的频率）和所有增加的脆弱性使得区域成为一个坏主意。但是，改变API的时间太晚了，我们留下了遗迹。

In the end, the combination of not nearly enough of a performance win (how often do you really close complex documents) with all the added fragility made zones a bad idea. Too late to change the APIs, though, and we are left with the vestiges.

这篇关于为什么在实施NSCopying时区域总是为零？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！