Variable Declaration, Initialization, and Data Types (Learn C Programming)

C is a strongly typed language. Every variable must be declared, indicating its data type, before it can be used. Declaration can also involve explicit initialization, giving the variable a value; a variable that is declared but not explicitly initialized is of uncertain value (and should be regarded as dangerous until it is initialized). In K&R C, declarations must precede all other statements, but in modern versions of C, this rule is relaxed so that you don’t have to declare a variable until just before you start using it:

int height = 2;
    int width = height * 2;
    height = height + 1; 

    int area = height * width;

The basic built-in C data types are all numeric: char (one byte), int (four bytes), float and double (floating-point numbers), and varieties such as short (short integer), long (long integer), unsigned short, and so on. A numeric literal may optionally express its type through a suffixed letter or letters: for example, 4 is an int, but 4UL is an unsigned long; 4.0 is a double, but 4.0f is a float. Objective-C makes use of some further numeric types derived from the C numeric types (by way of the typedef statement, K&R 6.7) designed to respond to the question of whether the processor is 64-bit; the most im‐ portant of these are NSInteger (along with NSUInteger) and CGFloat. You don’t need to use them explicitly unless an API tells you to, and even when you do, just think of NSInteger as int and CGFloat as float, and you’ll be fine.
To cast (or typecast) a variable’s value explicitly to another type, precede the variable’s name with the other type’s name in parentheses:

    int height = 2;
    float fheight = (float)height;

In that particular example, the explicit cast is unnecessary because the integer value will be cast to a float implicitly as it is assigned to a float variable, but it illustrates the notation. You’ll find yourself typecasting quite a bit in Objective-C, mostly to subdue the worries of the compiler.
Another form of numeric initialization is the enumeration, or enum (K&R 2.3). It’s a way of assigning names to a sequence of numeric values and is useful when a value represents one of several possible options. The Cocoa API uses this device a lot. For example, the three possible types of status bar animation might be defined like this:

    typedef enum {
       UIStatusBarAnimationNone,
       UIStatusBarAnimationFade,
       UIStatusBarAnimationSlide,

    } UIStatusBarAnimation;

That definition assigns the value 0 to the name UIStatusBarAnimationNone, the value 1 to the name UIStatusBarAnimationFade, and the value 2 to the name UIStatusBar- AnimationSlide. The upshot is that you can use the suggestively meaningful names without caring about, or even knowing, the arbitrary numeric values they represent. It’s a useful idiom, and you may well have reason to define enumerations in your own code.

That definition also assigns the name UIStatusBarAnimation to this enumeration as a whole. A named enumeration is not a data type, but you can pretend that it is, and the compiler can warn you if you mix enumeration types. For example, suppose you were to write this code: 

UIStatusBarAnimation anim = UIInterfaceOrientationPortrait;

That isn’t illegal; UIInterfaceOrientationPortrait is another name for 0, just as if you had said UIStatusBarAnimationNone. However, it comes from a different named enumeration, namely UIInterfaceOrientation. The compiler detects this, and warns you. Just as with a real data type, you can even squelch that warning by typecasting.
In iOS 7, the status bar animation types are defined like this:

    typedef NS_ENUM(NSInteger, UIStatusBarAnimation) {
        UIStatusBarAnimationNone,
        UIStatusBarAnimationFade,
        UIStatusBarAnimationSlide,

};
That notation was introduced in LLVM compiler version 4.0, which made its debut in Xcode 4.4. NS_ENUM is a macro, a form of preprocessor text substitution discussed at the end of this chapter; when the text substitution is performed, that code turns out to be shorthand for this:

    typedef enum UIStatusBarAnimation : NSInteger UIStatusBarAnimation;
    enum UIStatusBarAnimation : NSInteger {

        UIStatusBarAnimationNone,
        UIStatusBarAnimationFade,
        UIStatusBarAnimationSlide,

};
That looks almost exactly like the old way of expressing the same enumeration, but the new way involves some notation that isn’t part of standard C, telling the compiler what variety of integer value is being used here (it’s an NSInteger). This makes UIStatusBar‐ Animation even more like a genuine data type; in addition, the new enum notation lets Xcode help you more intelligently when performing code completion, as discussed in Chapter 9. Another macro, NS_OPTIONS, evaluates in Objective-C as a synonym of NS_ENUM (they are distinct only in C++ code, which is not discussed in this book).
There appears to be a native text type (a string) in C, but this is something of an illusion; behind the scenes, it is a null-terminated array of char. For example, in C you can write a string literal like this:
"string"
But in fact this is stored as 7 bytes, the numeric (ASCII) equivalents of each letter fol‐ lowed by a byte consisting of 0 to signal the end of the string. This data structure, called a C string, is rarely encountered while programming iOS. In general, when working with strings, you’ll use an Objective-C object type called NSString. An NSString is totally different from a C string; it happens, however, that Objective-C lets you write a literal NSString in a way that looks very like a C string:
@"string" 

Notice the at-sign! This expression is actually a directive to the Objective-C compiler to form an NSString object. A common mistake is forgetting the at-sign, thus causing your expression to be interpreted as a C string, which is a completely different animal.
Because the notation for literal NSStrings is modeled on the notation for C strings, it is worth knowing something about C strings, even though you won’t generally encounter them. For example, K&R lists a number of escaped characters (K&R 2.3), which you can also use in a literal NSString, including the following:

\n
A Unix newline character

\t 

A tab character

\"
A quotation mark (escaped to show that this is not the end of the string literal)

\\
A backslash 

K&R also mention a notation for concatenating string literals, in which multiple string literals separated only by white space are automatically concatenated and treated as a single string literal. This notation is useful for splitting a long string into multiple lines for legibility, and Objective-C copies this convention for literal NSStrings as well, except that you have to remember the at-sign:

    @"This is a big long literal string "
    @"which I have broken over two lines of code.";