Objective-C

rembrat

Member
SoSH Member
May 26, 2006
36,345
The last time I asked you guys for advice it was regarding JS and PHP. Once I grasped the concepts of OOP and the specifically MVC pattern for application design things clicked with the language. I really enjoy programming in JS. However, PHP, can go screw.
 
Anywho, my boss wants me to look at Objective C with the purpose of developing Mac OS applications. I've already got my feet wet via video tutorials and looking at the library but I would still like some books. I know there are programmers on here and I was hoping you guys could recommend me some literature and general things I should be wary of with the language. Thanks!
 

SumnerH

Malt Liquor Picker
Dope
SoSH Member
Jul 18, 2005
31,885
Alexandria, VA
rembrat said:
general things I should be wary of with the language. 
 
Is this your first time working with pointers?  Modern Objective C has pretty sophisticated gc and automatic memory management, but you'll still need to understand what's going on at the pointer level.  And that's something you need to be rock solid on.
 

rembrat

Member
SoSH Member
May 26, 2006
36,345
Absolutely. It's also the first time not having a garbage collector although I read some environments do this for you? But yes, I need to understand Memory Management. 
 
From what I've gathered so far, pointers just point to a memory address. And if I alloc something I need to dealloc it once I'm done with it. Though you can declare pointers without the * syntax that does the alloc/dealloc for you, I think? 
 
Feel free to correct me!!
 
Jul 10, 2002
4,279
Behind
Most of my early work was with C++, so I can't comment on Objective-C specifically, per-se, but are you thinking of smart pointers?  Some C++ ideas may have been brought to Objective-C, but my recommendations in regards to memory allocation are:
 
1. Try to declare as much as possible on the stack.
2. Use smart pointers (the last time I was heavily using C++, we were using the Boost libraries), RAII.
3. I used a lot of references, especially in function parameters.
 
It's been a while, but that's a good start (re: memory management).
 

Blacken

Robespierre in a Cape
SoSH Member
Jul 24, 2007
12,152
Modern Objective-C uses automated reference counting. C++ advice isn't really applicable unless you're writing Objective-C++ (which is a thing that exists) but even there you're often dealing with ARC'd objects from Cocoa and so you can't really use the normal C++ patterns in many cases. (I'd disagree with the general start-with-smart-pointers approach in pure C++, too, but I come from a game development background with regard to C++ and so there were more concerns related to it than most people necessarily have.)

rembrat: Objective-C pointers do point to memory addresses, but there's magic involved within clang to use them. Generally speaking (and this is really high level, there are places where it's not true) when you store an Objective-C object (anything inheriting from NSObject[1]) in a new variable, the thing it points to has its reference count incremented. When that variable no longer points to that, it's decremented, and when this count hits zero, it's deallocated and its memory is freed. In most cases, this means you don't need to dealloc yourself, but there are still instances where you might end up in non-ARC code (lots of libraries) so you do need to know when ARC is live or not.

You cannot allocate Objective-C objects on the stack (denoted by being a not-pointer, i.e. TypeName rather than TypeName*). You can allocate C structs on the stack, such as NSRect or NSPoint; these are just dumb chunks of data ordered in a predictable way (i.e., CGFloat[2]-CGFloat-CGFloat-CGFloat for an NSRect or CGFloat-CGFloat for NSPoint). If you have a pointer to a C struct, like an NSPoint*, it's a dumb pointer, so you have to handle memory management yourself--generally you'll allocate these on the stack, though, and they'll be automatically dealt with as they go out of scope. There are also cases where a library or something may return to you a pointer to a C type, and then you have to read the documentation to know whether you own the pointer (in which case you'll need to free it yourself) or whether it's still owned by the library and you just dereference it for data.

Long and the short of it, it's all pretty fucked and unless there's a reason you need Objective-C (instead of Java, MonoMac, etc.) I'd strongly consider looking elsewhere. It's possible to write very good Objective-C, but I wouldn't really recommend it as first-time exposure to a lower-level language. Too many weird things and too many inconsistencies.

Also, never ever use dot syntax in Objective-C because it obscures whether you're dealing with a struct or an object and makes it way harder to reason about.


[1] - You can have objects that don't inherit from NSObject but there's no good reason to do so when working with either iOS or OS X.

[2] - The definition of CGFloat changes from platform to platform. There are a few other data types for which this is true. Make sure you know what they are on your platform.
 

SumnerH

Malt Liquor Picker
Dope
SoSH Member
Jul 18, 2005
31,885
Alexandria, VA
rembrat said:
Absolutely. It's also the first time not having a garbage collector although I read some environments do this for you? But yes, I need to understand Memory Management. 
 
From what I've gathered so far, pointers just point to a memory address. And if I alloc something I need to dealloc it once I'm done with it. Though you can declare pointers without the * syntax that does the alloc/dealloc for you, I think? 
 
Feel free to correct me!!
Uhh, kind of. Blacken gets into some nuances. But pointers and pointer arithmetic are surprisingly complicated in practice (despite being theoretically very simple). Knowing the description of what they do isn't anywhere near being able to use them fluidly in programs, though mastering pointers is (IMO) one of the biggest steps in moving from someone who can hammer out some code to being a skilled programmer who really understands what's going on in their code.


I'd highly recommend that you learn straight C first before learning Objective C: Objective C has accreted a lot of stuff over the years, and you'll do better starting with the simpler dialect first and then learning the add-on features. It'll also help you understand why some of the weirdnesses and inconsistencies are there.

At least learn enough of the C basics to, say, comfortably know how to build a linked list and a red-black tree or skiplist, and to implement heap sort or quicksort, as well as doing pass-by-address and using function pointers as callbacks.
 

Blacken

Robespierre in a Cape
SoSH Member
Jul 24, 2007
12,152
^ Also agreed, if you absolutely _have_ to use Objective-C. Until I needed to integrate with C++ (a whole other topic), I was very comfortable doing GUI work in Java and MonoMac.
 

rembrat

Member
SoSH Member
May 26, 2006
36,345
Yea all that sounds like solid advice. I'll learn C first. Pretty excited. Thanks guys.
 

rembrat

Member
SoSH Member
May 26, 2006
36,345
Until I have to loop through an array just to get it to print or some primitive shit like that.
 

Jimy Hendrix

Member
SoSH Member
Jun 15, 2002
5,846
Any good beginner C tutorials out there? I've been working with garbage collected languages except for learning to program with C++ in high school before that all went Java and feel like I should get some low level pointer shit back in my repertoire before dynamic languages make me unfixably dumb with regards to that stuff.
 

Blacken

Robespierre in a Cape
SoSH Member
Jul 24, 2007
12,152
I'd start with Learn C the Hard Way. K&R doesn't teach much about modern C development.
 

rembrat

Member
SoSH Member
May 26, 2006
36,345
Yea, I found the online version of that and I have been flipping thorough it during my down time. I'll read it more thoroughly once I'm finished with K&R.

Any other intermediate books you guys want to suggest, just drop them in here. I find that I pick up on things the more I read them. I must have gone through 7 JS books last year alone.