this idea that one can 'migrate' from a language to another is really dumb IMHO :) If you are a competent programmer in any kind of OO programming language you should have no problems learning Objective-C reading a book or a tutorial and so on.
Right, and this is the one to read if you are coming from C++. No acres of verbiage explaining things you already know, just some quick 1:1 mappings and then explanations of things that are not 1:1.
e.g. 1:1: bool(C++) -> BOOL(Objective C) { domain is YES and NO }.
not 1:1: Every object is of type id. This is a tool for weak-typing – that gives you the aerial view of difference in type systems in one sentence right up front.
(I have to confess that despite writing quite a lot of Objective C, the part about "nil", "Nil", and "NULL" had escaped me, so I learned something in the first page of meat. I don't think I've ever used "Nil".)
in my opinion, the worst thing about learning objective-c is memory management. autorelease pools and retain/release/autorelease is a compromise, somewhere between C-style manual memory allocation and garbage collection. i think it's far and away the worst scheme out of the three. it's even worse with the new property syntax, which disguises a lot of retains and releases.
objective c 2.0 provides garbage collection, which is probably better. but it's not available on the iphone, so it might as well not exist for me.
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.
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.
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:
I reviewed the exception section, and was surprised to see no mention of this tidbit from Apple's developer documentation:
"You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server. You usually take care of these sorts of errors with exceptions when an application is being created rather than at runtime."
The reason for this is fairly straight-forward -- very little Objective-C code is exception-safe, it's relatively difficult to make it exception safe, and blindly traversing the call stack to the nearest exception handler will result in leaked resources and associated failures.
The correct way to handle errors in Objective-C is with NSError return values, which properly supports (among other things) reporting localized error messages and possible solutions to the user using standard UI, and optionally taking action on that solution using a recovery handler.
The Apple documentation on these subjects is quite comprehensive.
(edit) I should also mention that as of Objective-C 2.0, the language (Obj-C) and Apple's Foundation library are effectively linked. The compiler contains numerous direct dependencies on the Foundation library for the purpose of implementing properties, 'fast' enumeration, etc. While it used to be possible to claim that the languages and library were distinct (nothing prevented you from using a base class library other than Foundation), this is no longer necessarily the case. Any use of raw Objective-C requires the existence of Foundation-compatible protocol implementations.
Thus, any modern discussion of Objective-C 2.0 error handling is arguably lacking without mention of Foundation's facilities.
Likewise, discussion of Objective-C 1.0 error handling would have extended beyond the domain of Objective-C were it to include mention of the Foundation library's facilities.
