3 ms·

While I readily agree that the property syntactic sugar is ambitious and troublesome, I think it's overreaching to claim that reference counting is 'worse' than

While I readily agree that the property syntactic sugar is ambitious and troublesome, I think it's overreaching to claim that reference counting is 'worse' than C-style manual memory allocation. Reference counting combined with autorelease pools allows for simple shared ownership of shared references, without requiring domain knowledge regarding the ownership state of referenced objects. Autorelease pools allow for returning objects to callers without "passing ownership" -- the caller is free to ignore the return value, and ownership is held by the autorelease pool. I can't fathom how this can be claimed to be worse than API-defined single-owner object references.

allenbrunson 18y ago
C-style memory management might be tedious, but it's not hard. It's rare for me to make a mistake. I tend to structure my code so that a malloc() and its eventual free() are both in the same function, most of the time. C++-style RAII object lifetime management is even easier. Meanwhile, I've been coding in Objective-C since 2001, off and on, and I still get releases and retains in the wrong place sometimes. objc 2.0 property syntax means I can't even eyeball them to make sure they're balanced anymore. And I don't think I'm the only one. Go find a forum with newbie objc programmers, and I'll bet you a buck that most of the mistakes they're making are too many releases, not enough retains, making use of objects that have been freed, and so on.
- ankhmoop 18y ago
  Your original argument failed to define "worst-ness", but your followup implies a definition: Your opinion of the relative difficulty of comprehension. The C methodology you have presented ("... malloc() and its eventual free() are both in the same function") constrains ownership knowledge to a single function by simply disallowing more complex constructs (such as shared references held by container classes). This results in your C methodology providing significantly less functionality as compared to reference counting. Moreover, Objective-C's reference counting rules are logical, consistent, and short. - All objects are allocated with a reference count of 1. - All objects will be deallocated when their reference count reaches 0. - If you receive an object reference that you did not allocate, and you wish to maintain a reference to that object beyond the current scope, you must increment the reference count. Doing so will ensure that should the object's reference count be decremented elsewhere, the object will remain valid. - If you allocate an object or increment an object's reference count, it will not be deallocated until you decrement the reference count. Those rules -- coupled with utilities such as NSAutoreleasePool -- permit simple, language-wide ownership invariants. This is something that can not be achieved with "malloc/free". Lastly, most "newbie" programmers of any persuasion will necessarily have difficulty with basic language constructs, and will be considerably worse off if they have not have spent sufficient time studying the basic language documentation: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#//apple_ref/doc/uid/20000043-SW1 http://developer.apple.com/documentation/Cocoa/Conceptual/Me...

allenbrunson 18y ago

C-style memory management might be tedious, but it's not hard. It's rare for me to make a mistake. I tend to structure my code so that a malloc() and its eventual free() are both in the same function, most of the time. C++-style RAII object lifetime management is even easier. Meanwhile, I've been coding in Objective-C since 2001, off and on, and I still get releases and retains in the wrong place sometimes. objc 2.0 property syntax means I can't even eyeball them to make sure they're balanced anymore. And I don't think I'm the only one. Go find a forum with newbie objc programmers, and I'll bet you a buck that most of the mistakes they're making are too many releases, not enough retains, making use of objects that have been freed, and so on.

ankhmoop 18y ago
Your original argument failed to define "worst-ness", but your followup implies a definition: Your opinion of the relative difficulty of comprehension. The C methodology you have presented ("... malloc() and its eventual free() are both in the same function") constrains ownership knowledge to a single function by simply disallowing more complex constructs (such as shared references held by container classes). This results in your C methodology providing significantly less functionality as compared to reference counting. Moreover, Objective-C's reference counting rules are logical, consistent, and short. - All objects are allocated with a reference count of 1. - All objects will be deallocated when their reference count reaches 0. - If you receive an object reference that you did not allocate, and you wish to maintain a reference to that object beyond the current scope, you must increment the reference count. Doing so will ensure that should the object's reference count be decremented elsewhere, the object will remain valid. - If you allocate an object or increment an object's reference count, it will not be deallocated until you decrement the reference count. Those rules -- coupled with utilities such as NSAutoreleasePool -- permit simple, language-wide ownership invariants. This is something that can not be achieved with "malloc/free". Lastly, most "newbie" programmers of any persuasion will necessarily have difficulty with basic language constructs, and will be considerably worse off if they have not have spent sufficient time studying the basic language documentation: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#//apple_ref/doc/uid/20000043-SW1 http://developer.apple.com/documentation/Cocoa/Conceptual/Me...