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

Discussion in 'Mac Programming' started by glossywhite, Oct 6, 2009.

  1. glossywhite macrumors 65816


    Feb 28, 2008
    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]

    Attached Files:

  2. chown33 macrumors 604

    Aug 9, 2009
    Sailing beyond the sunset
    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.
  3. glossywhite thread starter macrumors 65816


    Feb 28, 2008
    They say Obj-C is *simple*??. It is not simple. It is hard to work out!.
  4. lee1210 macrumors 68040


    Jan 10, 2005
    Dallas, TX
    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.

  5. chown33 macrumors 604

    Aug 9, 2009
    Sailing beyond the sunset
    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.
  6. glossywhite thread starter macrumors 65816


    Feb 28, 2008
    Ah, but MANUAL memory management is used with iPhone SDK, and that NEEDS inner knowledge, no?.
  7. chown33 macrumors 604

    Aug 9, 2009
    Sailing beyond the sunset

    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:

    iPhone memory management guide:

    Mac garbage collection guide:
  8. Catfish_Man macrumors 68030


    Sep 13, 2001
    Portland, OR
    "manual" here refers to retain/release, not C style manual memory management.

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

    also, I think people should learn the implementation details eventually. It's interesting, and can be useful.
  9. GorillaPaws macrumors 6502a


    Oct 26, 2003
    Richmond, VA
    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.
  10. whooleytoo macrumors 604


    Aug 2, 2002
    Cork, Ireland.
    The way I think of it:

    Column A:

    Column B:

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

Share This Page