Clive, that kid in the picture above is Ellie, she's not a "he", and do you have her permission to post her pic on your site? Rather rude, mate.

Whoops -- thanks for the correction!! I'm a bonehead.

As to the permission to reprint the photo ... none explicit, though I didn't think I needed it, since my re-use of those components of the Bluejacking web site would probably be covered under copyright law as "review"; I'm writing about the site and its contents and musing thereon. That law doesn't allow you to plunder the entire site, but as far as I understand it, it lets you use snippets -- an image, a few quoted paragraphs, etc. -- in making your point.

Though certainly there's a *lot* of image-plundering going on in the blogosphere that is considerably more expansive and probably not covered, true.

Nice site. thx.

If Ellie had read your so called review I doubt she would give u permission to use her photo. I expect u will ask her permission now?

Ellie will be made aware of this, if you care to read the home page of her site at bluejackq.com you will find it says quote" ©2003 jellyellie, all rights reserved.
If you quote this site or copy excerpts please acknowledge bluejackQ.com as the source, provide a clear link to www.bluejackQ.com and email bluejackQ.com to let us know this has been done."

obviously it says in laymans terms email the owner before you tea leaf the picture and state where the picture is from i.e. copyright bluejackq.com

Sure, I'd be happy to mention the original source of the picture if you want. Already done, in fact.

But some variables are immortal. These variables are declared outside of blocks, outside of functions. Since they don't have a block to exist in they are called global variables (as opposed to local variables), because they exist in all blocks, everywhere, and they never go out of scope. Although powerful, these kinds of variables are generally frowned upon because they encourage bad program design.

Since the Heap has no definite rules as to where it will create space for you, there must be some way of figuring out where your new space is. And the answer is, simply enough, addressing. When you create new space in the heap to hold your data, you get back an address that tells you where your new space is, so your bits can move in. This address is called a Pointer, and it's really just a hexadecimal number that points to a location in the heap. Since it's really just a number, it can be stored quite nicely into a variable.

This variable is then used in various lines of code, holding values given it by variable assignments along the way. In the course of its life, a variable can hold any number of variables and be used in any number of different ways. This flexibility is built on the precept we just learned: a variable is really just a block of bits, and those bits can hold whatever data the program needs to remember. They can hold enough data to remember an integer from as low as -2,147,483,647 up to 2,147,483,647 (one less than plus or minus 2^31). They can remember one character of writing. They can keep a decimal number with a huge amount of precision and a giant range. They can hold a time accurate to the second in a range of centuries. A few bits is not to be scoffed at.

That gives us a pretty good starting point to understand a lot more about variables, and that's what we'll be examining next lesson. Those new variable types I promised last lesson will finally make an appearance, and we'll examine a few concepts that we'll use to organize our data into more meaningful structures, a sort of precursor to the objects that Cocoa works with. And we'll delve a little bit more into the fun things we can do by looking at those ever-present bits in a few new ways.

This code should compile and run just fine, and you should see no changes in how the program works. So why did we do all of that?

Inside each stack frame is a slew of useful information. It tells the computer what code is currently executing, where to go next, where to go in the case a return statement is found, and a whole lot of other things that are incredible useful to the computer, but not very useful to you most of the time. One of the things that is useful to you is the part of the frame that keeps track of all the variables you're using. So the first place for a variable to live is on the Stack. This is a very nice place to live, in that all the creation and destruction of space is handled for you as Stack Frames are created and destroyed. You seldom have to worry about making space for the variables on the stack. The only problem is that the variables here only live as long as the stack frame does, which is to say the length of the function those variables are declared in. This is often a fine situation, but when you need to store information for longer than a single function, you are instantly out of luck.

When Batman went home at the end of a night spent fighting crime, he put on a suit and tie and became Bruce Wayne. When Clark Kent saw a news story getting too hot, a phone booth hid his change into Superman. When you're programming, all the variables you juggle around are doing similar tricks as they present one face to you and a totally different one to the machine.

But variables get one benefit people do not

This will allow us to use a few functions we didn't have access to before. These lines are still a mystery for now, but we'll explain them soon. Now we'll start working within the main function, where favoriteNumber is declared and used. The first thing we need to do is change how we declare the variable. Instead of

This back and forth is an important concept to understand in C programming, especially on the Mac's RISC architecture. Almost every variable you work with can be represented in 32 bits of memory: thirty-two 1s and 0s define the data that a simple variable can hold. There are exceptions, like on the new 64-bit G5s and in the 128-bit world of AltiVec