• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: copying an object instance using NSCopyMemoryPages
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: copying an object instance using NSCopyMemoryPages


  • Subject: Re: copying an object instance using NSCopyMemoryPages
  • From: Matthew Johnson <email@hidden>
  • Date: Sat, 22 Nov 2003 18:09:18 -0600

The chances that your code will work are quite limited because of this:

<snip>
int retainCount = [self retainCount];
[self dealloc];
NSCopyMemoryPages(newSelf, self, myClass->instance_size);
int i;
for (i = 1; i < (retainCount); i++) {
[self retain];
}
<snip>
The code above is making assumptions about how NSArray is internally organized. This, however, is very bad and dangerous because even if the assumptions are valid for the current system version, they may already break with the next minor system update (i.e. 10.3.2).

So for example, there is nothing that guarantees that an NSArray would consist of just one single memory block. It could be that the memory block pointed to by newSelf/self contains just maintenance information like the number of objects in the array and that the actual array contents is stored in another memory block.

In fact NSArray like some other classes, most notably NSDictionary and NSString, are technically quite complicated beasts because they are not only class clusters but also toll-free bridged with their CF equivalents. Consequently you can not know what the exact layout of an NSArray instance is at runtime because Foundation can choose among a number of different internal classes when it creates an instance - each with their own specialized layout.

I understand that the code is quite risky which is why I am asking for opinions. I am aware of the class cluster issue and was trying to work around it by verifying that the class of both the old and the new array were the same:

Class myClass = [self class];
Class newArrayClass = [newSelf class];
if (myClass != newArrayClass) {
[self doesNotRecognizeSelector:[invocation selector]];
} else {

If this isn't successful I was not doing the copy. My assumption here was that if the class of both is the same I should be able to get away with the copy because I am deallocating the old instance (and thus cleaning up any memory not stored in the main block). The new instance would contain pointers to any additional blocks in the memory I am copying, and everything should be fine at that point.

It just now occurred to me that any additional blocks for the new instance would be deallocated as soon as the new array goes out of scope even if I am still pointing to them...

This is really a concept at this point and I'm interested in hearing thoughts on the idea of a PseudoMutable concept. I would be interested in hearing any implementation ideas others might have. I just took a stab at one approach. If there are other better approaches to this I'd be glad to hear what they might be...

Matthew
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >copying an object instance using NSCopyMemoryPages (From: Matthew Johnson <email@hidden>)
 >Re: copying an object instance using NSCopyMemoryPages (From: Dietmar Planitzer <email@hidden>)

  • Prev by Date: App Won't Run From Within XCode
  • Next by Date: Need to draw a NSImage into a graf port
  • Previous by thread: Re: copying an object instance using NSCopyMemoryPages
  • Next by thread: Waiting for a Cocoa app to die...
  • Index(es):
    • Date
    • Thread