Why zone is always nil while implementing NSCopying?

Question

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

- (id)copyWithZone:(NSZone *)zone
{
    if (zo         


        

Answer 1

Zone is a legacy from the old days when computers had 8 megs or less of RAM.

Check this out (3.1.2 Memory Allocation and Zones):

http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_3.html

There is also a good discussion of this over on cocoa builder (well it was on the cocoa dev mailing list) from about 10 years ago. This is exactly what @bbum was saying.

http://www.cocoabuilder.com/archive/cocoa/65056-what-an-nszone.html

Apparently this used to be documented in the Apple docs, but it was changed at some point since 2007-06-06.

http://www.cocoadev.com/index.pl?NSZone

Answer 2

NSZone was deprecated a long time ago. The fact that it's still in method signatures (e.g. +allocWithZone: and -copyWithZone:) are for backwards compatibility.

Answer 3

A NULL zone just means 'use the default zone'. Zones aren't used by the modern Objective C runtime anymore and cannot be used with ARC at all.

See documentation

Answer 4

NSZone is now an undocumented class because it is quite old, its purpose was to allocate objects on the heap using the same set of virtual memory pages. However it is mostly not used anymore, but since it was used before, that parameter is still there for backwards compatibility.

Answer 5

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.

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).

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.

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.