PDA

View Full Version : Declaring Variables: Grrrr...




ataylor2009
Feb 19, 2009, 03:40 PM
I'm in the midst of trying (again) to learn Cocoa and Objective-C on the Mac. I've hired a programmer to write my first iPhone app, mainly because I want to get it out into the wild before my idea's time has come and gone. I don't have a lifetime to learn to program it myself. One of the side benefits, of course, is that when it's all said and done, I'll have all of the source code for a commercially-viable iPhone app at my disposal to dissect and study.

Until then, though, I'm doing it the hard (and much cheaper) way: I'm re-reading all of my Cocoa and Objective-C reference books. It has become apparent to me as I go through all of this stuff again that what I find difficult is the system CocObjC uses to declare variables. I understand the model-view-controller paradigm, the messaging paradigm, object-oriented programming concepts, etc. But I cannot for the life of me follow something like

NSColor *color = graphic.color;
CGFloat xLoc = graphic.xLoc;
BOOL hidden = graphic.hidden;
int textCharacterLength = graphic.text.length;

(For what it's worth, these statements were copied verbatim from page 20 of Apple's The Objective-C 2.0 Programming Language.) I'm not worried about the stuff on the right side of the statement; I'm concerned with what's on the left side. And I sort of understand some of what's on the left: I savvy that hidden is the name of a variable that holds a boolean (yes/no or on/off or 0/1) value whose type is BOOL. I savvy that textCharacterLength is the name of a variable that holds a numerical value of type INT.

I do NOT savvy what xLoc is. I suspect that it is the name of a variable that holds a floating-point value, but I don't know why it's of type CGFloat.

I particularly do NOT savvy what *color is. Why the asterisk? What's special about it? Why do some variables have asterisks and some do not? How do you know when to use it? Apple just assumes the reader knows the difference; I suspect that somewhere, buried in Apple's developer documentation library, there's an explanation for this, but I haven't stumbled across it yet.



lee1210
Feb 19, 2009, 03:59 PM
All of the things you are having trouble with are C things, not really objective-C things. If one were to know C, saying to them "Every object is on the heap, so you store a pointer" is all they really need to know to understand object declarations.

Coming from a place where you do not know C makes this worse. I don't know that in this post I can cover a full lesson in pointers, so i will not try. I will say that when the * appears between the type and the variable name it means "pointer to type x". So the type of color is "pointer to NSColor". A pointer means the address to a position in memory, where one will find data of that particular type. You can have a pointer to any sort of thing.

CGFloat is a different sort of thing. I am not on a Mac, so i can't specifically reference the file and line that defines it, but it is basically a typedef to a floating point number designed to deal with the 64-bit transition. There is more here:
http://developer.apple.com/documentation/Cocoa/Conceptual/Cocoa64BitGuide/64BitChangesCocoa/chapter_3_section_4.html#//apple_ref/doc/uid/TP40004247-CH4-SW13

In C you can use the keyword "typedef" to make your own, new "type". It could just be a new name for int, it could be a new name for int*, it could be a struct, a pointer to a struct, etc. The point is to make code more portable and more readable, but if you don't know what sort of thing that typedef is, unfortunately the opposite in terms of readability is true.

-Lee

Sayer
Feb 19, 2009, 05:10 PM
Usually you see a pointer when you deal with an object that is typically more complex than just one value.

NSColor is a complex object with multiple components, you don't just set it to a single value since it has multiple separate values inside of it (like an accordion file folder).

A CFFloat is only one type of value, a floating-point number. A BOOL is one byte so you set its value directly.

That kind of thing tripped me up long ago when I started with C/C++ and it can still get rather cumbersome in some cases with double-dereferencing and such.