The brilliant Daniel Raeburn, the most intelligent comics-critic I've ever read, is putting together a book-length study of Ivan Brunetti's work, which should be out later this year. Keep your eyes open for it--if it's as good as his studies of Daniel Clowes, Jack Chick, Chris Ware, and Mexican "historietas," then it'll definitely be worth picking up ...

hey man i got hooked in ivan brunetti's work back in 98, because i saw a lot of himself in me and up till today i still do. manic-depressed/philosopher constantly surrounded by ignorant assholes and such. i keep finding more and more page on the net with his work so that is good, to me at least. i don't know what brunetti is up to now though, i think he is into programming or something. anyway i hope the medication works...

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.

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 a variable is finished with it's work, it does not go into retirement, and it is never mentioned again. Variables simply cease to exist, and the thirty-two bits of data that they held is released, so that some other variable may later use them.

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.

Note first that favoriteNumbers type changed. Instead of our familiar int, we're now using int*. The asterisk here is an operator, which is often called the "star operator". You will remember that we also use an asterisk as a sign for multiplication. The positioning of the asterisk changes its meaning. This operator effectively means "this is a pointer". Here it says that favoriteNumber will be not an int but a pointer to an int. And instead of simply going on to say what we're putting in that int, we have to take an extra step and create the space, which is what does. This function takes an argument that specifies how much space you need and then returns a pointer to that space. We've passed it the result of another function, , which we pass int, a type. In reality, is a macro, but for now we don't have to care: all we need to know is that it tells us the size of whatever we gave it, in this case an int. So when is done, it gives us an address in the heap where we can put an integer. It is important to remember that the data is stored in the heap, while the address of that data is stored in a pointer on the stack.