macOS refcount (alloc, retain, release) - have I got this right?

[glossywhite]

Just knocked up a quick diagram in CS4 - is this correct?. Please note that my comments here, DO NOT correspond entirely with the diagram. Thanks:

1/ Alloc == +1

2/ Retain (1) == +2

3/ Retain (2) == +3

4/ Release (1) == +2

5/ Release (2) == +1

6/ Release (any) == 0 [dealloc]

 

[chown33]

The refcount may not actually be 0 when dealloc is called, or ever.

If the refcount is 1 when release is called, the system doesn't need to assign 0 to refcount, because the memory holding the refcount is about to be deallocated anyway, so any value it holds is irrelevant. All that's relevant is that the object's memory is about to be deallocated, so dealloc is called.

If you're trying to understand retain/release by mentally tracking the refcount, you're doing it wrong. The crucial concept is ownership, and how that is expressed by retain/release to claim and relinquish ownership. The Cocoa memory management guide discusses this all in terms of ownership. Tracking refcount can mislead you, because retain/release doesn't necessarily change the refcount in the way a naive interpretation might suppose.

 

[glossywhite]

They say Obj-C is *simple*??. It is not simple. It is hard to work out!.

 

[lee1210]

Objective-C's additions to straight C are pretty simple. C itself is not simple, and Cocoa and Foundation, which are built on Objective-C and C, are not simple, either.

-Lee

 

[chown33]

They say Obj-C is *simple*??. It is not simple. It is hard to work out!.

It is simple if you just follow the published rules. Seriously. It's only hard because you're trying to work out the implementation.

You never have to understand refcounts or worry about the overall state of allocated memory. All you have to do is write each class, function, or method to manage its owned objects. It only gets confusing when you try to figure out how the overall system is implemented, and how retain/release actually work.

When you call fopen() on a file pathname, do you worry about how the OS reads directory entries, figures out the block on the disk, and then caches it in memory? Do you concern yourself with the differences between FAT, HFS, or NTFS? Not if you want to stay sane. It's the same thing with retain/release. Commit the rules of object ownership to memory (yours, not the computer's), and everything will work as if by magic, without you having to understand the least little bit of how it's implemented.

Understand the principles, use the abstractions, and follow the rules. You can dig into the implementation details later, if and when it becomes necessary.

 

[glossywhite]

It is simple if you just follow the published rules. Seriously. It's only hard because you're trying to work out the implementation.

You never have to understand refcounts or worry about the overall state of allocated memory. All you have to do is write each class, function, or method to manage its owned objects. It only gets confusing when you try to figure out how the overall system is implemented, and how retain/release actually work.

When you call fopen() on a file pathname, do you worry about how the OS reads directory entries, figures out the block on the disk, and then caches it in memory? Do you concern yourself with the differences between FAT, HFS, or NTFS? Not if you want to stay sane. It's the same thing with retain/release. Commit the rules of object ownership to memory (yours, not the computer's), and everything will work as if by magic, without you having to understand the least little bit of how it's implemented.

Understand the principles, use the abstractions, and follow the rules. You can dig into the implementation details later, if and when it becomes necessary.

Ah, but MANUAL memory management is used with iPhone SDK, and that NEEDS inner knowledge, no?.

 

[chown33]

No.

retain/release IS manual memory management, and it exists on iPhone (Cocoa touch). Read memory management guide for retain/release. It discusses it in terms of ownership and relinquishing ownership. If you follow the ownership rules, you don't have to know anything about how it's implemented internally.

If you want classical C-style malloc()/calloc() and free(), I'm pretty sure you can do that on iPhone, too. But if you're writing Objective-C, that's just retain/release.

The iPhone lacks garbage collected (GC) memory management, also called automatic memory management. GC is only present on Mac OS X.

Mac retain/release memory management guide:
http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/MemoryMgmt/index.html

iPhone memory management guide:
http://developer.apple.com/iPhone/library/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html

Mac garbage collection guide:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/GarbageCollection/index.html

 

[Catfish_Man]

"manual" here refers to retain/release, not C style manual memory management.

<edit> beaten by a minute. *shakes fist* </edit>

<edit2>
also, I think people should learn the implementation details eventually. It's interesting, and can be useful.
</edit2>

 

[GorillaPaws]

It is simple if you just follow the published rules. Seriously. It's only hard because you're trying to work out the implementation.

Understanding the implementation helped me understand the "why's" of the memory management rules, and it actually made things easier for me. I guess people learn differently though, so you should go with what works best for you.

Manual memory management is a little tricky, but much less so than some of the other fun things you'll soon be learning about (e.g. undo, the responder chain, notifications). Chown33 is 100% right about thinking of memory management in terms of ownership though--it's much easier that way.

 

[whooleytoo]

Ah, but MANUAL memory management is used with iPhone SDK, and that NEEDS inner knowledge, no?.

The way I think of it:

Column A:
alloc
copy
new
retain

Column B:
release
autorelease

Every call from Column A should have a matching call from Column B. I think that's simple (and hope that's correct... )