Re: NSMutableDictionary autorelease chrashes application
Re: NSMutableDictionary autorelease chrashes application
- Subject: Re: NSMutableDictionary autorelease chrashes application
- From: Andy Lee <email@hidden>
- Date: Fri, 18 Jul 2008 23:52:12 -0400
On Jul 18, 2008, at 8:31 PM, Michael Ash wrote:
On Fri, Jul 18, 2008 at 7:48 PM, Andy Lee <email@hidden> wrote:
We'll just have to disagree on how odd the objections are.
Corner case or not, we must understand that retains, wherever they
occur,
must be balanced with releases. Therefore we must understand that
the same
object can "own" another object multiple times -- it happens all
the time.
In fact, at the time you take ownership of something, you have no
idea how
many times you've owned it already. IMO this is not mere hair-
splitting.
It blows away the normal English concept of ownership, which is
binary: you
as an individual either own something or you don't.
I think it is hair splitting simply because it doesn't matter. You
only see this problem if you take a global view of the situation. But
the whole point of Cocoa memory management is to remove the
requirement to take such a global view. The concept of ownership can
be applied to the individual pointer variables, which makes this all
go away.
The funny thing is, I didn't take such a global view until I found
that something about the word "ownership" nagged at me. I usually
take a very local and low-level view. In the case where I receive an
object I own (to use the terminology), I think: "I don't know or care
what the actual retain count and autorelease count are; I only know I
have to treat this object *as if* it has a retain count of 1 and no
autoreleases." In the other case, I think: "I don't know or care
etc.; I only know I have to treat this object *as if* it has a retain
count of 1 and an autorelease count of 1."
It's only when the ownership metaphor was applied that I questioned
whether the abstraction holds up.
This is why I never call the retain count a reference count,
although it
seems like the two terms have become interchangeable lately (I
could swear
that once upon a time the distinction mattered). Reference counts
are about
ownership; retain counts are about bookkeeping.
I've never heard such a distinction made before. I've seen "reference
count" used to describe bookkeeping all over the place, for example in
many primitive garbage collection systems.
I've definitely heard the distinction made, but it was a long, long
time ago. As far as I can tell from Google, I'm the only one who
remembers, because everybody uses them interchangeably.
The distinction, as it was made to me, is that a retain count isn't
necessarily the number of references your program has to the object,
whereas something like the reference count in a simple C++ String
class is precisely the number of references your program has to the
char buffer.
(Note: my knowledge of C++ is very outdated, but I believe, from the
link you included below, that the old simple String class is still a
relevant example. I thought it was very clever when it was explained
to me.)
Using
"ownership" to indicate responsibility for freeing an object is
nothing unusual.
Hm. Apparently it isn't. Okay, that makes me a little more
comfortable with the term.
The only unusual thing Cocoa does with it is allow
multiple owners.
I'm confused by this statement. Take that simple C++ String class
again. If you have:
String a = "aaa";
String b = a;
String c = a;
...don't a, b, and c all own the underlying char buffer? (And yes, a
char buffer isn't an object, but that's what the article you linked to
is referring to when it mentions ownership.)
--Andy
See for example this random LinuxDevCenter article on C++ memory
management:
http://www.linuxdevcenter.com/pub/a/linux/2003/06/19/cpp_mm-1.html
Same terminology, same basic concepts, just much greater difficulty
due to ownership being singular.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden