

Effective textbook for migrating to Objective-C from C++ - ivanzhao
http://ktd.club.fr/programmation/fichiers/cpp-objc-en.pdf
Effective textbook for people migrating to Objective-C from C++
======
antirez
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.

~~~
jws
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".)

------
allenbrunson
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.

~~~
ankhmoop
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
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
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/Me...](http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#//apple_ref/doc/uid/20000043-SW1)

------
jorgem
I bought a whole book to tell me the same information as in the PDF. I like
this PDF better.

The book was odd, though: Not one mention of exceptions or error handling in a
whole book.

Sigh

~~~
silencio
Out of curiosity, which book was this?

And on a sidenote, Apple has some extensive documentation on that available in
the docs.

~~~
ivanzhao
not really sure. I found it through an arbitrary google search.

~~~
silencio
ah, sorry if it wasn't clear, i meant to ask jorgem about the book that didn't
mention exceptions :)

although, i have seen this particular pdf floating around before, and i keep
forgetting to bookmark it and this time i did, so thank you :)

~~~
jorgem
Learn Objective–C on the Mac (Learn Series)

------
jws
Nicely done. Apple-centric, but then most people going to objective C are
going for Apple.

