On Oct 23, 2009, at 4:19 PM, Michael de Haan wrote:
When adding a bookmark, the bookmark object is initialized thus:
- init
{
if (self = [super init])
{
title = @"new title";
self.creationDate = [NSDate date];
}
return self;
}
**property declarations for title and creation date are @property
(copy) NSString *title // and NSDate * creationDate respectively**
Back in the calling method, creationDate is again called:
Bookmark *newBookmark = [[Bookmark alloc] init];
[newBookmark setCreationDate:[NSDate date]];
Is the reason that the date created in the initializer is an
autoreleased object, and thus the method adding the bookmark needs
it's own "owned" copy?
No. It appears that setting the creationDate property again is just
redundant.
The expression [NSDate date] in -[Bookmark init] returns an object
without any attendant ownership responsibility nor lifetime
guarantee. Colloquially, that might be referred to as "an
autoreleased object", but there's no actual reason to believe it's
autoreleased. You don't know that, nor do you care. You just need to
know that you don't own it, so you shouldn't release it, and if you
want it to live for any specific period of time beyond the current
call stack, you should retain it (after which you do own it).
When that date object is then assigned to "self.creationDate", that
invokes the setCreationDate: setter, which makes its own copy of the
object. So, there's no memory management implication of the later
explicit invocation of setCreationDate: in the document class. It
truly is purely redundant.
(Had the -init assigned to the creationDate ivar directly, rather than
using dot syntax to invoke the setter, then it would be a bug to fail
to retain the date object.)
Now I **thought** I understood this, but "title" in the init method
is directly assigned to it's ivar, and also handed back to the
calling method, without any further intervention.......or should I
read memory management again!!! :-)
I would say that's a bug in the sample, although an extremely minor
one without any chance of causing actual problems. The title ivar
gets assigned to point to a string literal. String literals are
permanent. They are not allocated from the heap, and they are never
deallocated. Retains and releases on them are no-ops. Still, since
if the title is ever set to something else the old value will be
released, it's proper that the original value should be retained. In
other words, that line in the -init method should be:
title = [@"new title" retain];
There is a lot of discussion about the fact that dealloc is not
necessarily called each time an object is disposed of.
Is there such discussion? The only time that dealloc is not called
for an object is when it isn't fully released. This will happen in
the case of a leak or similar bug and when an application quits. When
an application quits, it is not necessary to individually release each
object in its memory because the OS will reclaim the memory as part of
process tear-down. Other than that, though, dealloc will be called
when an object is deallocated by being fully released.
The rules of memory management would seem to indicate that in the
case of initialization of doc.m:
- (id)init
{
self = [super init];
if (self)
{
collection = [[NSMutableArray alloc] init];
}
return self;
}
"collection" needs to be released. [ collection holds all the
bookmarks].
You are correct.
Now, there is no dealloc method called in this project's doc.m
Indeed, there are no dealloc methods in the entire sample, which makes
it buggy. There should be one for the MyDocument and Bookmark classes.
So, my question is when is it appropriate to **omit** the dealloc
entirely?
When objects of the class never hold ownership of any other objects.
You can get away without one for any object which is certain to live
until the application quits, but it's still poor style, in my opinion.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
