[jawngee]

How is the most ignorant comment in this thread voted up?

First of all, he offers no evidence that memory management in objective-c is resource or effort intensive. He can't, because it's not. This is not hard:

    -(id)initWithSomeNumber:(NSNumber *)aNumber {
        ...
        someField=[[SomeObject alloc] init];
        someOtherField=[aNumber copy];  // or retain, your call.
        ...
    }

    -(void)dealloc {
        [someField release];
        [someOtherField release];
        [super dealloc];
    }

How is that hard exactly? There are only 4 rules you need to follow for memory management in Objective-C/Cocoa/CocoaTouch:

* If you use a convenience method, eg [NSString stringWithFormat:...] you don't own it, so don't release it.

* If you use alloc, copy or new, you own it, so release it.

* Implement dealloc to release fields you own.

* Never invoke dealloc directly.

I mean you can be as snarky as you want dude, I write Cocoa apps all day long (as well as web apps and mobile apps) and I can tell you and the original poster, are either idiots or lazy. I'm going to go with lazy.

[jamesg]

It's totally about laziness! But that's what computers are all about -- I could store printed versions of all of my documents in a filing cabinet, and go and manually sort them every time I needed a different ordering, but I'm lazy! I use a database!

I just don't see why laziness should be restricted to users. Developers are lazy too.

You're right that there are only 4 rules (or more or less depending on your formulation), but I don't care. I'd rather take the time to have another martini. Or, y'know, implement features that make my users happy.

And it definitely gets harder when there are more moving parts. You're right that the rules are simple, but the execution of those rules gets more complex as you add more components, more threads, remoting, etc. I never said it was impossible, or up there with Fermat's Last Theorem or anything like that. Just that this is work the computer could be doing for me. I want to be lazy, but Apple won't let me.

[varikin]

Memory management is Obj-C has issues. The documentation is spotty at explaining how to property handle it, or maybe it is an issue with the organization of the documentation cause I can't always find what I need, but I know it is there. When I started, I keep hearing the general rule of thumb, "if you don't alloc/init it, you don't need to release it." Except no one mentioned you have release properties. I never alloc/init them. Along with that, difference between an ivar and property is poorly documented. The fact that "aField = x" is different than "self.aField = x" and can mess up memory management was lost on me.

My problem with the documentation, as I said before is mostly organization. Along with that, some of these concepts are defined in ways that only make sense if you already know the language and framework.

After a couple projects and code reviews, I think I understand it now. It is not that we are lazy for not understanding or liking it; it is that it isn't intuitive or simple like GC.

[HectorRamos]

If your property is defined as retain in your header, you are claiming ownership for it and so it needs to be released in your dealloc method.

This is covered in the basic Memory Management doc http://developer.apple.com/library/mac/#documentation/Cocoa/...

[SeanLuke]

I love Obj-C dearly. But Obj-C's reference counting scheme is, and always has been, much more cognitive load than a GC. In Java the above would be roughly:

    public myObject(Number aNumber) {
        someField = new SomeObject();
        someOtherField = aNumber;
        }

...and that's it. No dealloc, no forgetting to release, no forgetting to retain objects you hold onto, no trying to figure out how to handle cyclic references (or indeed if certain references are cyclic at all). Just set it and forget it.

[binaryfinery]

I've written memory managers used in console games for the N64 (4Mb), PS2 (32Mb) and a complete memory tracking system for Unreal Engine 3 on XBox360 (OMG 512Mb).

I use MonoTouch for iOS development. Why? Because I can build complex object graphs without having to maintain, in my head or in external documentation, the acyclic version of the graph. In a GC language I can create graphs that are happily cyclic, and have every reason to be, and yet have them deallocated when the application nulls the last reference.

In a reference counted system that desires cyclic pointers, one or more of those pointers have to be chosen as non-reference-incrementing pointers - and likewise one must remember not to release them either.

Memory management in Objective-C (without GC) is no effort provided one is making applications with simple object interactions, such as the plethora of tree-based hierarchies. Reference counting is great for that.

So it could be that the OP is lazy, or it could be that they have experience with problems that you do not. If you believe that OP actually requires a lesson on the basic rules of reference counted memory management (since thats what you provided) then I suggest that you are underestimating the experience of your detractors, which in turn leads me to believe that you are overestimating yours.

[jamesg]

This is very well put. Much more insightful than my glib comments below. Thanks dude!