Who own the object return by insertNewObjectForEntityForName:inManagedObjectContext:

Question

My test code:

NSManagedObjectContext *context;
.....
NSAutoreleasePool *pool = [NSAutoreleasePool new];
User *u = (User *)[NSEntityDescription insertNewObjectForEntityForName:@"User" inManagedObjectContext:context];
NSLog(@"after create:%d", [u retainCount]);
[context deleteObject:u];
NSLog(@"after delete:%d", [u retainCount]);
[context save:NULL];
NSLog(@"after save:%d", [u retainCount]);
[pool drain];
[pool release];
NSLog(@"after pool release:%d", [u retainCount]);
[u release];
NSLog(@"after user release:%d", [u retainCount]);
u.loginName = @"aaaa";

The result:

2010-08-13 10:04:54.558 BriefCase[7448:207] after create:2
2010-08-13 10:04:54.560 BriefCase[7448:207] after delete:3
2010-08-13 10:04:54.561 BriefCase[7448:207] after save:1
2010-08-13 10:04:54.562 BriefCase[7448:207] after pool release:1
2010-08-13 10:04:54.563 BriefCase[7448:207] after user release:0
Program received signal:  “EXC_BAD_ACCESS”.

According to the Core Data document, insertNewObjectForEntityForName:inManagedObjectContext: will return an autoreleased object. So after delete, save and release pool, the object u should be deallocated. What I understand wrong?

Another question, after [u release], why [u retainCount] can return 0, I think it should be "EXC_BAD_ACCESS".

Answer 1

Core Data owns it, you do not. If you want to gain ownership then retain it. However, just because you do not own it does not guarantee that it will be dealloc'ed on the next firing of the autorelease pool. Core Data may decide to hang onto it for an unknown period of time beyond your use.

Short answer: follow the retain/release rules and leave the memory management of Core Data up to Core Data. It does a lot of things behind the scenes.

Also, you do not need to cast an id. -insertNewObjectForEntityForName: inManagedObjectContext:, like most methods in Core Data and throughout Objective-C, returns id. id never needs to be cast. Casting is just lying to the compiler and can introduce subtle bugs.

Lastly, you should never pay attention to or rely on -retainCount. Just because you released it does not mean that some part of the foundation does not still have a reference to it. -retainCount has no value.

Return of id

There is no compiler warning because it is not a warning. Returning id means it is a generic object and it can be assigned to anything. In fact, you can leave it as an id and still call any method on it in the world. Naturally if the method is not there at runtime then you will get an exception. It is part of the fundamentals of Objective-C and its dynamic nature. Something that is vital to learn.

User *u = [NSEntityDescription insertNewObjectForEntityForName:@"User" inManagedObjectContext:context];

Is the correct handling. Unlike Java and C#; Objective-C is not a strongly cast language and because you are sending messages as opposed to calling methods, those calls are resolved at runtime so it is rather irrelevant what you claim the object is anyway. It is helpful to claim it is a User so that you can get some compile time checking, but if you try and call -thisMethodDoesNotExist on it, you will compile with only a warning. The message will still attempt to be sent at runtime and only then will you get an exception. This is a fundamental and vital portion of Objective-C.

-retainCount

-retainCount is not reliable and should never be used. What you get back from it can be meaningless.

In addition, you are using Core Data and testing it against a Core Data object, that makes matters even worse. Even though you are in a single thread, there is no guarantee (and it is in fact quite unlikely) that Core Data is only using a single thread internally. That is one of the many, many, reasons that -retainCount should not be used. It is not transparent enough and relying on it, even in testing, is a bad idea.