On Jul 18, 2008, at 8:31 PM, Michael Ash wrote:
On Fri, Jul 18, 2008 at 7:48 PM, Andy Lee <[EMAIL PROTECTED]> 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 (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 [EMAIL PROTECTED]

Reply via email to