Why is the zone always zero when implementing NSCopying?

This may be a simple question, but why use the 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 to copy an array with objects.

 [[NSArray alloc] initWithArray:myArray copyItems:YES]]; 
+15
ios objective-c nsarray nscopying
Oct 28 '11 at 19:52
source share
5 answers

The answer of Kevin and Robin is the most accurate. The answer to the Oscars is pretty close to the correct one. But neither the Gnustep documentation, nor the reasons logancautrell exists for zones to exist are correct.

Zones were originally created - first NXZone, then NSZone - so that objects selected from one zone are relatively continuous in memory, this is true. As it turned out, this does not reduce the amount of memory that the application uses; in most cases, it slightly increases it.

The big goal was to be able to massively destroy many objects.

For example, if you were to load a complex document into a document-based application, the disruption of the object graph when closing the document can be quite significant.

Thus, if all objects for a document were allocated from one zone, and allocation metadata for this zone was also in this zone, then destroying all objects associated with the document would be as cheap as simply deleting a zone (which was really cheap - "here, system, return these pages" - one function call).

It turned out to be inoperative. If one link to an object in a zone leaked from the zone, your application would move BOOM as soon as the document was closed, and there was no way for the object to indicate everything that had to do with it should stop. Secondly, this model also fell prey to the resource scarcity problem that is often found in the GC'd system. That is, if the graphic object of the document is stored on resources without memory, it was not possible to efficiently clean these resources before the destruction of the zone.

In the end, the combination almost does not benefit from productivity (how often you really close complex documents), and all the added fragility created the zones as a bad idea. It’s too late to change the APIs and we are left with the leftovers.

+25
Oct 28 '11 at
source share

The NULL zone simply means "use the default zone." Zones are no longer used by the modern Objective-C environment and cannot be used with ARC at all.

See documentation

+4
Oct 28 '11 at 19:57
source share

NSZone long out of date. The fact that it is still in the method signatures (e.g. +allocWithZone: and -copyWithZone: is for backward compatibility.

+3
Oct 28 '11 at 19:56
source share

A zone is a legacy from the old days when computers had 8 megabytes or less RAM.

Check it out (3.1.2 Memory and zone allocation):

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

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

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

Apparently, this was documented in Apple docs, but from some point on 2007-06-06 it was changed.

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

+1
Oct 28 '11 at 19:56
source share

NSZone 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 no longer used, but since it was used earlier, this parameter still exists for backward compatibility.

+1
Oct 28 '11 at 19:56
source share



All Articles